[issue2075] Float number comparision problem
will added the comment: The issue is reproduced under WIN32, version info as follows: Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2075> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2075] Float number comparision problem
New submission from will: c=22.99*5.0 print c==114.95 """This will produce false""" c=22.99*4.0 print c==91.96 """This will produce true""" """This is not expected behavior for python""" -- components: Interpreter Core, Library (Lib) messages: 62306 nosy: tsxy severity: normal status: open title: Float number comparision problem type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2075> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23258] Cannot Install Python 3.4.2 on Windows 7 64 bit / screen print attached
Will added the comment: Had the exact same problem. Windows 7 / 64-bit All I can get from the MSIexec log is: Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action UpdatePip, location: B:\lang\python\v03.04\python.exe, command: -m ensurepip -U --default-pip === Logging stopped: 11-Feb-2015 22:13:46 === _ I tried this various ways -- from command line, as administrator, msiexec /a, verbose logging -- NO LUCK. I think it is really broken -- nosy: +aplatypus ___ Python tracker <http://bugs.python.org/issue23258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2234] cygwinccompiler.py fails for latest MinGW releases.
Will Brown <[EMAIL PROTECTED]> added the comment: Same problem in version.py, line 100 (StrictVersion) -- nosy: +wmbrown ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2234> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2234] cygwinccompiler.py fails for latest MinGW releases.
Will Brown <[EMAIL PROTECTED]> added the comment: Yes, same problem. Multiple files. I should have read the discussion more carefully. My note was redundant. Will -- William Brown -- -- Boeing Networked Systems Technology -- Kent:253.657.5586 Blvu:425.373.2738 > -Original Message- > From: Benjamin Peterson [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 10, 2008 2:25 PM > To: Brown, William J > Subject: [issue2234] cygwinccompiler.py fails for latest > MinGW releases. > > > Benjamin Peterson <[EMAIL PROTECTED]> added the comment: > > This seems to be the same as #3013. > > -- > nosy: +benjamin.peterson > > ___ > Python tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue2234> > ___ > ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2234> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2234] cygwinccompiler.py fails for latest MinGW releases.
Will Brown <[EMAIL PROTECTED]> added the comment: None of the above will work on both '2.18.50.20080523' & '1.2.3a' -- William Brown -- -- Boeing Networked Systems Technology -- Kent:253.657.5586 Blvu:425.373.2738 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2234> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2234] cygwinccompiler.py fails for latest MinGW releases.
Will Brown <[EMAIL PROTECTED]> added the comment:
Maybe I have a problem with my test code...
import re
def test_re(out_string):
result = re.search('(\d+\.\d+(\.(\d+))?([ab](\d+))?)', out_string)
print '--- msg00622 ---'
print result.group(1)
print result.group(2)
print result.group(3)
print result.group(4)
print
if __name__ == '__main__':
out_string = '2.18.50.20080523'
test_re(out_string)
out_string = '1.2.3a'
test_re(out_string)
out_string = '2.18.50a.20080523'
test_re(out_string)
Results...
--- msg00622 ---
2.18.50
.50
50
None
--- msg00622 ---
1.2.3
.3
3
None
--- msg00622 ---
2.18.50
.50
50
None
I would expect GNU to have a standard for version strings so this
doesn't happen to EVERYONE when they deviate from the expected.
A quick check in Google returned the following links for other
packages...
http://publib.boulder.ibm.com/tividd/td/ITCM/SC23-4712-01/en_US/HTML/cmm
st19.htm
http://java.sun.com/j2se/versioning_naming.html
http://www.osgi.org/javadoc/r4/org/osgi/framework/Version.html
Given that, I think I prefer 1 to 2.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2234>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3726] Allow ', ' delimiters in logging.config.fileConfig()
New submission from Will Maier <[EMAIL PROTECTED]>: Currently, logging.config.fileConfig() inconsistently handles lines like: [handlers] keys = spam, eggs [formatters] keys = foo, bar It does, however, correctly handle the ', ' delimiter in the [loggers] section. This is because the various _install_*() functions in logging.config aren't consistent about whether (and when) or not they strip whitespace when generating key names. Though the stdlib documentation only includes examples in the [handlers] and [formatters] section with ',' delimiters, it seems reasonable to expect that logging.config.fileConfig() should handle ', '. The attached test demonstrates the failure and suggests a solution. Thanks! whitespace -- components: Library (Lib) files: logging.diff keywords: patch messages: 72134 nosy: wcmaier severity: normal status: open title: Allow ',' delimiters in logging.config.fileConfig() type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file11304/logging.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3726> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6676] expat parser throws Memory Error when parsing multiple files
Will Grainger added the comment: I don't think this is a python specific problem. I have just seen the same error when working with the expat library from C, and the cause is using the same parser to read multiple files. -- nosy: +willgrainger ___ Python tracker <http://bugs.python.org/issue6676> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2147] int operations no longer overflow
Will Robinson added the comment: Just jumping in to say the colleague Neal refers to is me, and I'm interested in the resolution to this bug. Thanks in advance for your help. -- nosy: +willrobinson __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2147> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2473] logging.LogRecord should know how to handle dict-like args
New submission from Will Maier <[EMAIL PROTECTED]>: In (at least) Python 2.5.2, logging.logRecord provides a very useful facility to interpolate formatted strings. This feature expands an *args sequence; if that sequence has only one element and that element is a dictionary, LogRecord uses the dictionary to interpolate keyword formatted strings. This is incredibly useful, but the LogRecord __init__() method includes a rather arbitrary type-specific check that prevents users from passing dict-like objects to the log methods: logging.__init__.py:204..238 class LogRecord: [...] def __init__(self, name, level, pathname, lineno, msg, args, exc_info, func=None): [...] if args and (len(args) == 1) and args[0] and (type(args[0]) == types.DictType): args = args[0] This restriction prevents the user from passing eg a subclass of UserDict.DictMixin. Now, __init__() clearly does need to do _some_ checking of args, but it would be nice if that checking accepted dict-like objects. I haven't come up with a good way to do this myself yet, but I figured I'd submit the request now. Thanks! -- components: Library (Lib) messages: 64415 nosy: wcmaier severity: normal status: open title: logging.LogRecord should know how to handle dict-like args type: feature request versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2473> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37839] makesetup Doesn't Handle Defines with Equal Sign
New submission from Will Bond : Using 3.8.0b3 on macOS. I'm doing a custom compile with (heavy) modifications to Modules/Setup.local. Whenever I add a define rule to a module line that includes an equal sign, e.g.: _sqlite3 -DMODULE_NAME=_sqlite3 _sqlite/module.c _sqlite/cache.c _sqlite/connection.c _sqlite/cursor.c _sqlite/microprotocols.c _sqlite/prepare_protocol.c _sqlite/row.c _sqlite/statement.c _sqlite/util.c -I../env/include -I\$(srcdir)/Modules/_sqlite ../env/lib/libsqlite3.a makesetup appears to treat this as a Makefile variable definition, which places the rule in the wrong part of the Makefile. In my situation, this causes _sqlite3 to be compiled as a shared library instead of statically. I see this was peripherally reported at https://bugs.python.org/issue35184, but in that case the =1 was just dropped rather than solving the underlying issue. For many situations, dropping the =1 works, but in others it is not. Not that this is necessarily helpful, but I do know that this used to work with Python 3.3. -- messages: 349543 nosy: wbond priority: normal severity: normal status: open title: makesetup Doesn't Handle Defines with Equal Sign type: compile error versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue37839> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38193] http.client should be "runnable" like http.server
New submission from Will Boyce : I think it would be both sensible and useful if the `http.client` library exposed a "runnable" interface (similar to `http.server`). I would suggest keeping it simple, for example: python -m http.client python -m http.client -o -- components: Library (Lib) messages: 352586 nosy: Will Boyce priority: normal severity: normal status: open title: http.client should be "runnable" like http.server type: enhancement ___ Python tracker <https://bugs.python.org/issue38193> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36702] test_dtrace failed
will rogers added the comment:
I also encountered this on Scientific Linux 7.4 (Linux
3.10.0-693.11.6.el7.x86_64) while trying to build Python 3.8.0.
I think it is due to differences in versions of 'dtrace' on different platforms.
On my MacOS-X v10.14.6 (Mojave) system, the 'dtrace' command has a -q (quiet
the output) option.
On SL 7.4, it does not. The options are quite different.
This is output and versions from my test run:
./python ./Tools/scripts/run_tests.py
== CPython 3.8.0 (default, Oct 29 2019, 14:37:09) [GCC 4.8.5 20150623 (Red
Hat 4.8.5-16)]
== Linux-3.10.0-693.11.6.el7.x86_64-x86_64-with-glibc2.17 little-endian
== cwd: /opt/Python-3.8.0/build/test_python_30482
== CPU count: 2
== encodings: locale=UTF-8, FS=utf-8
Below is an error from the test log that shows the 'q' option being rejected
from 'dtrace' (linux'):
0:10:16 load avg: 1.79 Re-running test_dtrace in verbose mode
skipped "dtrace(1) failed: ('/usr/bin/dtrace', 'invalid option',
'-q')\nUsage /usr/bin/dtrace [--help] [-h | -G] [-C [-I]] -s File.d [-o
]"
Assuming 'dtrace' is run as a sub-process, the different versions could be
producing very different results.
I attached a (clipped) version of my 'make test' output, it is essentially the
same as sayno996's results.
There are also some error from 'test_nis" which can be ignoed for this issue.
I hope this helps.
--
nosy: +willrogers3
versions: +Python 3.8
Added file: https://bugs.python.org/file48687/make_test-clipped.txt
___
Python tracker
<https://bugs.python.org/issue36702>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14965] super() and property inheritance behavior
Will Razen added the comment: @simonzack Your superprop.py doesn't work for multiple inheritance, because you're using __thisclass__.__mro__ in each step instead of the initial object mro -- nosy: +willrazen ___ Python tracker <https://bugs.python.org/issue14965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14965] super() and property inheritance behavior
Will Razen added the comment: Fixed superprop.py workaround, now works with multiple inheritance and follows mro adequately. Renamed to duper.py as inspired by Torsten. Uploading here and also to https://gist.github.com/willrazen/bef3fcb26a83dffb6692e5e10d3e67ac -- Added file: https://bugs.python.org/file50057/duper.py ___ Python tracker <https://bugs.python.org/issue14965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44468] Shouldn't `typing.get_type_hints()` default `globalns` to `{}` instead of skipping base classes?
New submission from Will Chen :
An issue was recently closed that caused synthetic classes and base classes
with invalid `__module__` attributes to raise `KeyError()` in
`typing.get_type_hints()`:
https://bugs.python.org/issue41515
However, the implemented solution appears to be to skip those classes
completely with a `continue` statement, instead of getting the annotations that
may still be present by using an empty globals dictonary:
https://github.com/python/cpython/pull/25352/files#diff-ddb987fca5f5df0c9a2f5521ed687919d70bb3d64eaeb8021f98833a2a716887
In order to work around this issue in my local install of Blender, I had to
change `.get_type_hints()` to use an empty dictionary for `globalns` when
encountering invalid modules, rather than skipping them:
https://developer.blender.org/T88986#1179812
>From reading the commit where the broken behaviour was first introduced— Which
>was described/designed as "backwards compatible"— It looks like the original
>behaviour was also to use an empty dictionary, and never skip:
https://github.com/python/cpython/commit/f350a268a7071ce7d7a5bb86a9b1229782d4963b#diff-ddb987fca5f5df0c9a2f5521ed687919d70bb3d64eaeb8021f98833a2a716887R1501
Using an empty dictionary also seemed to be mentioned in the bug report linked
above.
IMO using an empty dictionary and still returning annotations from classes with
invalid modules seems like it'd be more sensible, predictable, and
backwards-compatible, while skipping base classes is likely to just replace the
obvious `KeyError()` with less reproducible and nastier errors caused by
returning incomplete type hints.
--
messages: 396205
nosy: willchencontact
priority: normal
severity: normal
status: open
title: Shouldn't `typing.get_type_hints()` default `globalns` to `{}` instead
of skipping base classes?
type: behavior
versions: Python 3.10, Python 3.11
___
Python tracker
<https://bugs.python.org/issue44468>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44468] Shouldn't `typing.get_type_hints()` default `globalns` to `{}` instead of skipping base classes?
Change by Will Chen : -- keywords: +patch pull_requests: +25437 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26862 ___ Python tracker <https://bugs.python.org/issue44468> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44468] Shouldn't `typing.get_type_hints()` default `globalns` to `{}` instead of skipping base classes?
Will Chen added the comment: I opened a PR with a fix and a couple comments on its method: https://github.com/python/cpython/pull/26862 I also *think* I signed the CLA correctly. Not sure. I used my login name here, rather than my Github login, but my account is linked. Didn't add any blurb/changelog notes. Would that be needed? Thanks for looking at this issue quickly! Let me know if there's anything else I can or should do. -- ___ Python tracker <https://bugs.python.org/issue44468> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41515] typing.get_type_hints generates KeyError
Change by Will Chen : -- nosy: +WCA nosy_count: 6.0 -> 7.0 pull_requests: +25458 pull_request: https://github.com/python/cpython/pull/26862 ___ Python tracker <https://bugs.python.org/issue41515> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39547] hmac.new() default parameter change not mentioned in changelog
New submission from Will Bond : When running code on Python 3.8 that previous was running 3.3, I ran into the issue that the default value for the digestmod parameter of hmac.new() has been changed to backwards-incompatible value. I generally would have expected such a break to show up in https://docs.python.org/3/whatsnew/3.8.html#api-and-feature-removals. If not there, somewhere on the 3.8 changelog page. -- assignee: docs@python components: Documentation messages: 361329 nosy: docs@python, wbond priority: normal severity: normal status: open title: hmac.new() default parameter change not mentioned in changelog versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue39547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40603] slice does not slice
New submission from Will Bradshaw : slice cannot be hashed which make some operations significantly more annoying. see https://groups.google.com/forum/#!topic/comp.lang.python/SvhkWwSDeIw -- components: ctypes files: patches.zip messages: 368693 nosy: Will Bradshaw priority: normal severity: normal status: open title: slice does not slice type: behavior versions: Python 3.9 Added file: https://bugs.python.org/file49149/patches.zip ___ Python tracker <https://bugs.python.org/issue40603> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42980] argparse: GNU-style help formatter
New submission from Will Noble : argparse allows GNU-style long options (with '=' in between the option and the value as opposed to a space): https://docs.python.org/3/library/argparse.html#option-value-syntax Call it pickiness, but I'd like to be able to print the help message in that format. Looking at the code, a simple refactor would be much cleaner than implementing my own custom help formatter and having to copy-paste a bunch of implementation details that are potentially subject to change in future releases. I'll submit a patch shortly. -- components: Library (Lib) messages: 385359 nosy: will priority: normal severity: normal status: open title: argparse: GNU-style help formatter type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42980] argparse: GNU-style help formatter
Change by Will Noble : -- keywords: +patch pull_requests: +23098 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24275 ___ Python tracker <https://bugs.python.org/issue42980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42980] argparse: GNU-style help formatter
Will Noble added the comment: The main contribution of my PR is simply factoring out _format_option_with_args as an overridable method. Note that this actually enables subclassing HelpFormatter to produce all the examples you presented above with 1-3 trivial lines of code, as opposed to overriding the entire _format_action_invocation which is 20 lines in the base class. If HelpFormatter had a stable internal structure (i.e. some sort of assurance that it's overridable methods were not subject to change), I wouldn't have bothered including an implementation of GnuStyleLongOptionsHelpFormatter in this PR, since I could just implement it downstream as-needed. However, I chose to push it upstream because a) it's trivial and non-invasive and b) it establishes a use-case of _format_option_with_args for posterity, just in case anybody came in later and saw such a trivial, "private" (underscore-prefixed) method and decided to inline it. This lack of perceived stability is alluded to in https://bugs.python.org/issue42966. My preferred solution would be to refactor HelpFormatter to have more overridable methods like this, make them non-"private", document them properly, and keep them relatively stable. In order to do that, we'd want to establish all the desired use-cases and be sure to craft the method structure in such a way that they're all supported. Since that would be a somewhat daunting design task and probably not high on the priority list atm, I think this small incremental improvement pushes things in the right direction; establishing a desirable use-case without committing to too many implementation details yet. -- ___ Python tracker <https://bugs.python.org/issue42980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42980] argparse: GNU-style help formatter
Will Noble added the comment: Ya I was following the precedent of non-documentation figuring that formal documentation should be done for the entire class and that would be a much larger undertaking and maybe involve further refactoring. I could potentially undertake that task in the future but I think it's out-of-scope for this change. -- ___ Python tracker <https://bugs.python.org/issue42980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30197] Enhance swap_attr() and swap_item() in test.support
Will Chill added the comment: Thought I'd send -- nosy: +wburchill7 Added file: https://bugs.python.org/file49498/March 23rd 2017.htm ___ Python tracker <https://bugs.python.org/issue30197> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30197] Enhance swap_attr() and swap_item() in test.support
Change by Will Chill : Removed file: https://bugs.python.org/file49498/March 23rd 2017.htm ___ Python tracker <https://bugs.python.org/issue30197> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29708] support reproducible Python builds
Change by Will Thompson : -- nosy: -Will Thompson ___ Python tracker <https://bugs.python.org/issue29708> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28053] parameterize what serialization is used in multiprocessing
Will S added the comment: Documentation would be appreciated. I have a project that uses BaseManager, Client, and Listener to create some servers and clients. I would like to update the project to work with Python 3 and would prefer to update the clients and the servers separately (i.e. switch the client to Python 3 while the server is run with Python 2.7). However, BaseManager uses connection.Client which uses connection._ConnectionBase which uses reduction.ForkingPickler without a protocol argument. It seems the default protocol is 3 on Python 3.6 and 2 on Python 2.7 (contrary to the comment above about v2 being used). I just want to set the protocol version to 2 in Python 3.6. Can I do that with the changes added by this patch? I tried creating pickle2reducer.py like this: from multiprocessing.reduction import ForkingPickler, AbstractReducer class ForkingPickler2(ForkingPickler): def __init__(self, *args): if len(args) > 1: args[1] = 2 else: args.append(2) super().__init__(*args) @classmethod def dumps(cls, obj, protocol=2): return ForkingPickler.dumps(obj, protocol) def dump(obj, file, protocol=2): ForkingPickler2(file, protocol).dump(obj) class Pickle2Reducer(AbstractReducer): ForkingPickler = ForkingPickler2 register = ForkingPickler2.register dump = dump and then putting import pickle2reducer multiprocessing.reducer = pickle2reducer.Pickle2Reducer() at the top of my module before import multiprocessing.connection but I still see "ValueError: unsupported pickle protocol: 3" on the server when I connect with a Python 3.6 client. -- nosy: +Will S ___ Python tracker <http://bugs.python.org/issue28053> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28053] parameterize what serialization is used in multiprocessing
Will S added the comment: Just to follow up in case anyone comes across my last message later: I just had to change the last line from multiprocessing.reducer = pickle2reducer.Pickle2Reducer() to multiprocessing.context._default_context.reducer = pickle2reducer.Pickle2Reducer() -- ___ Python tracker <http://bugs.python.org/issue28053> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35540] dataclasses.asdict breaks with defaultdict fields
New submission from Will T :
_asdict_inner attempts to manually recursively deepcopy dicts by calling
type(obj) with a generator of transformed keyvalue tuples @
https://github.com/python/cpython/blob/b2f642ccd2f65d2f3bf77bbaa103dd2bc2733734/Lib/dataclasses.py#L1080
. defaultdicts are dicts so this runs but unlike other dicts their first arg
has to be a callable or None:
import collections
import dataclasses as dc
@dc.dataclass()
class C:
d: dict
c = C(collections.defaultdict(lambda: 3, {}))
d = dc.asdict(c)
assert isinstance(d['d'], collections.defaultdict)
assert d['d']['a'] == 3
=>
Traceback (most recent call last):
File "boom.py", line 9, in
d = dc.asdict(c)
File
"/Users/spinlock/.pyenv/versions/3.7.1/lib/python3.7/dataclasses.py", line
1019, in asdict
return _asdict_inner(obj, dict_factory)
File
"/Users/spinlock/.pyenv/versions/3.7.1/lib/python3.7/dataclasses.py", line
1026, in _asdict_inner
value = _asdict_inner(getattr(obj, f.name), dict_factory)
File
"/Users/spinlock/.pyenv/versions/3.7.1/lib/python3.7/dataclasses.py", line
1058, in _asdict_inner
for k, v in obj.items())
TypeError: first argument must be callable or None
I understand that it isn't this bit of code's job to support every dict (and
list etc.) subclass under the sun but given defaultdict is stdlib it's imo
worth supporting explicitly.
--
components: Library (Lib)
messages: 332166
nosy: wrmsr
priority: normal
severity: normal
status: open
title: dataclasses.asdict breaks with defaultdict fields
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue35540>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30537] Using PyNumber_AsSsize_t in itertools.islice
Will Roberts added the comment: Note that this issue also seems to affect other methods in the itertools package, such as permutations. -- nosy: +Will Roberts ___ Python tracker <http://bugs.python.org/issue30537> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30537] Using PyNumber_AsSsize_t in itertools.islice
Will Roberts added the comment: Thanks for feedback, Serhiy and Raymond! Github PR now has reverted changes except to the calls in islice_new; I am happy to squash if you would like. Serhiy, this is my first time poking around in CPython code. What are the potential consequences of making `itertools.islice` less atomic/thread-safe, and/or possibly releasing the GIL? Are there any gotchas to watch out for in this patch specifically? I've modelled my changes on the code in listobject.c [list_subscript], but I would love to hear if there's a better way to do things. Raymond, I'd also be curious to learn about any code weirdness or inefficiency you have in mind. I agree with you that there might not be a compelling use-case here. The SO question looks to be a bit contrived; however, the interesting bits to me here are that the behaviour of numpy interacting with itertools has changed since py27, and also that the proposed workarounds/solutions seem ... inelegant? Need a numpy integer be explicitly coerced to int in this context when the type implements an __index__ method? -- ___ Python tracker <http://bugs.python.org/issue30537> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30537] Using PyNumber_AsSsize_t in itertools.islice
Will Roberts added the comment: Github PR adds simple test, as well as an entry in Misc/NEWS. -- ___ Python tracker <http://bugs.python.org/issue30537> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29708] support reproducible Python builds
Will Thompson added the comment: For what it's worth, in Endless OS we still saw slight variations between builds in the .pyc files, even with all the source files' mtimes set to the epoch (ie. equivalent to setting & supporting SOURCE_DATE_EPOCH, I believe). Looking at the contents of the file suggested it was just reordering of class fields; indeed, we only saw this on Python versions where hash randomization is enabled by default, and disabling hash randomization made the output reproducible. -- nosy: +Will Thompson ___ Python tracker <https://bugs.python.org/issue29708> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32162] typing.Generic breaks __init_subclass__
Will T added the comment: I believe I'm experiencing a related bug in the new (3.7) version unfortunately. The current version of typing.Generic.__init_subclass__ isn't chaining to super(Generic, cls).__init_subclass__, meaning Generic's position in class bases can prevent subsequent bases from working properly. I can currently work around it with this unsightly hack but it's obviously suboptimal: _old_generic_init_subclass = object.__getattribute__(ta.Generic, '__init_subclass__').__func__ @classmethod # noqa def _new_generic_init_subclass(cls, *args, **kwargs): # noqa _old_generic_init_subclass(cls, *args, **kwargs) super(ta.Generic, cls).__init_subclass__(*args, **kwargs) ta.Generic.__init_subclass__ = _new_generic_init_subclass # noqa -- nosy: +wrmsr ___ Python tracker <https://bugs.python.org/issue32162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33207] typing.Generic does not correctly call super().__init_subclass__
New submission from Will T : Per the docs ( https://docs.python.org/3/reference/datamodel.html#object.__init_subclass__ ) this should be chain-calling super but currently doesn't, and thus breaks base classes listed after it which depend on this functionality. Attached a test for a real-world usecase of mine. Originally noted in https://bugs.python.org/issue32162? but on a new ticket as requested. Thanks :) -- components: Library (Lib) files: generic_init_subclass.py messages: 314828 nosy: wrmsr priority: normal severity: normal status: open title: typing.Generic does not correctly call super().__init_subclass__ type: behavior versions: Python 3.7 Added file: https://bugs.python.org/file47513/generic_init_subclass.py ___ Python tracker <https://bugs.python.org/issue33207> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32162] typing.Generic breaks __init_subclass__
Will T added the comment: Done: https://bugs.python.org/issue33207 - thanks for the quick response! -- ___ Python tracker <https://bugs.python.org/issue32162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32873] Pickling of typing types
Will T added the comment: I believe I hit a bug with this fix (just pulled the code a few min ago): In [10]: pickle.loads(pickle.dumps(typing.List)) Out[10]: typing.List In [11]: pickle.loads(pickle.dumps(typing.FrozenSet)) --- PicklingError Traceback (most recent call last) in () > 1 pickle.loads(pickle.dumps(typing.FrozenSet)) PicklingError: Can't pickle typing.Frozenset: attribute lookup Frozenset on typing failed The cause is in _GenericAlias.__init__ name = orig_name[0].title() + orig_name[1:] Maybe just pass the name explicitly? For context I originally hit this trying to explicitly getattr(typing, alias_name) not by pickling but I'm pleased to see that's at least apparently intended to be valid use (I need to get the underlying special's parameter variance which is lost when you give it args). -- nosy: +wrmsr ___ Python tracker <https://bugs.python.org/issue32873> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31782] Add a timeout to multiprocessing's Pool.join
New submission from Will Starms : Pool's join function currently (3.6.3) lacks a timeout, which can cause the managing thread to sleep indefinitely when a pool worker hangs or starts misbehaving. Adding a timeout allows the owning thread to attempt a join and, after the timeout, return to other tasks, such as monitoring worker health. In my specific situation, I have a Pool running a task on a large set of files. If any single task fails, the whole operation is ruined and the pool should be terminated. A task can communicate with the main thread through error_callback, but if the thread has already called join, it can't check until join returns, after the Pool has finished all processing. Attached is an incredibly simple patch to the current (3.6) cpython implementation that emulates threading.thread.join's behavior. -- components: Library (Lib) files: cpython_timeout.patch keywords: patch messages: 304350 nosy: Will Starms priority: normal severity: normal status: open title: Add a timeout to multiprocessing's Pool.join type: enhancement versions: Python 3.6 Added file: https://bugs.python.org/file47219/cpython_timeout.patch ___ Python tracker <https://bugs.python.org/issue31782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31782] Add a timeout to multiprocessing's Pool.join
Will Starms added the comment: A timeout alternative that raises TimeoutError -- Added file: https://bugs.python.org/file47220/cpython_raise_timeout.patch ___ Python tracker <https://bugs.python.org/issue31782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31782] Add a timeout to multiprocessing's Pool.join
Will Starms added the comment: I've realized that my patch may not be ideal for general-purpose use, but it's a good start for a discussion on the proper way to implement a timeout. My patch (which is based on a more involved modification to Pool) assumes that the joins after the first will complete within a timely fashion, which is not necessarily true. While this prevents leaving the pool in a half-joined state, it can still get stuck joining other components or at least take significantly longer than the requested timeout. Assuming that joining an already-joined object is safe, or it can be wrapped in an if statement to check before rejoining, I feel the best solution would be to reduce the timeout as joins complete, either raising (much easier) or returning (like threading.thread, but makes an is_alive function more difficult) when the remaining timeout time hits zero. -- ___ Python tracker <https://bugs.python.org/issue31782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19684] IDLE on OS X 10.6.8 crashes when opening a file
Will Adams added the comment: For some reason I got the impression that this only applied to some graphics library routines so I ignored the warnings. Thanks for the reply and sorry to take your time. On Nov 21, 2013, at 11:58 AM, Ned Deily wrote: > > Ned Deily added the comment: > >> From the crash reports, it appears that you were trying to use IDLE with the >> Apple-supplied Tcl and Tk frameworks. OS X 10.6.x was the first release of >> the newer Aqua Cocoa Tk and it was very problematic. You should have seen a >> warning message when IDLE 2.7.6 started, warning you about this and advising >> you to go to http://www.python.org/download/mac/tcltk/ for further >> information. (The warning is also on the download pages and in the >> installer Readme.) You will read there: "you should only use IDLE or >> tkinter with an updated third-party Tcl/Tk 8.5, like ActiveTcl 8.5, >> installed". Do that and IDLE 2.7.6 should behave properly. > > -- > resolution: -> out of date > stage: -> committed/rejected > status: open -> closed > > ___ > Python tracker > <http://bugs.python.org/issue19684> > ___ -- ___ Python tracker <http://bugs.python.org/issue19684> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19684] OS X 10.6.8 Crash when opening a file
New submission from Will Adams: Apologies in advance if I am posting incorrectly. This is my first post here. IDLE crashes when I open a *.py file on my old mac pro from IDLE. I haven't seen this on version 3.3.2, but I need to do some work in version 2.7 today so I downloaded 2.7.6 and ran into this system dump: Process: Python [1832] Path:/Applications/Python 2.7/IDLE.app/Contents/MacOS/Python Identifier: org.python.IDLE Version: 2.7.6 (2.7.6) Code Type: X86 (Native) Parent Process: launchd [143] Date/Time: 2013-11-21 11:24:30.080 -0600 OS Version: Mac OS X 10.6.8 (10K549) Report Version: 6 Interval Since Last Report: 3154609 sec Crashes Since Last Report: 42 Per-App Interval Since Last Report: 642 sec Per-App Crashes Since Last Report: 5 Anonymous UUID: 3134C4C6-DD18-4049-8638-9A3C0FBC6343 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x44014000 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Application Specific Information: objc_msgSend() selector name: release Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x91b97f8b objc_msgSend + 27 1 com.apple.CoreFoundation0x95f57bcd _CFAutoreleasePoolPop + 253 2 com.apple.Foundation0x94287976 NSPopAutoreleasePool + 76 3 com.apple.Foundation0x9428789e -[NSAutoreleasePool drain] + 130 4 Tk 0x0072df18 XQueryPointer + 2393 5 Tk 0x0072e219 Tk_MacOSXSetupTkNotifier + 634 6 Tcl 0x005f5ab4 Tcl_DoOneEvent + 310 7 _tkinter.so 0x002f1322 Tkapp_MainLoop + 450 8 org.python.python 0x000c4230 PyEval_EvalFrameEx + 25344 9 org.python.python 0x000c6a2c PyEval_EvalCodeEx + 2012 10 org.python.python 0x000c4825 PyEval_EvalFrameEx + 26869 11 org.python.python 0x000c554c PyEval_EvalFrameEx + 30236 12 org.python.python 0x000c6a2c PyEval_EvalCodeEx + 2012 13 org.python.python 0x000c6b77 PyEval_EvalCode + 87 14 org.python.python 0x000eaf5c PyRun_FileExFlags + 172 15 org.python.python 0x000eb284 PyRun_SimpleFileExFlags + 532 16 org.python.python 0x00103412 Py_Main + 3410 17 Python 0x1f65 start + 53 Thread 1: Dispatch queue: com.apple.libdispatch-manager 0 libSystem.B.dylib 0x9196a382 kevent + 10 1 libSystem.B.dylib 0x9196aa9c _dispatch_mgr_invoke + 215 2 libSystem.B.dylib 0x91969f59 _dispatch_queue_invoke + 163 3 libSystem.B.dylib 0x91969cfe _dispatch_worker_thread2 + 240 4 libSystem.B.dylib 0x91969781 _pthread_wqthread + 390 5 libSystem.B.dylib 0x919695c6 start_wqthread + 30 Thread 2: 0 libSystem.B.dylib 0x91962ac6 select$DARWIN_EXTSN + 10 1 Tcl 0x0062b737 Tcl_InitNotifier + 1643 2 libSystem.B.dylib 0x91971259 _pthread_start + 345 3 libSystem.B.dylib 0x919710de thread_start + 34 Thread 3: 0 libSystem.B.dylib 0x91969412 __workq_kernreturn + 10 1 libSystem.B.dylib 0x919699a8 _pthread_wqthread + 941 2 libSystem.B.dylib 0x919695c6 start_wqthread + 30 Thread 4: com.apple.CFSocket.private 0 libSystem.B.dylib 0x91962ac6 select$DARWIN_EXTSN + 10 1 com.apple.CoreFoundation0x95f9ac53 __CFSocketManager + 1091 2 libSystem.B.dylib 0x91971259 _pthread_start + 345 3 libSystem.B.dylib 0x919710de thread_start + 34 Thread 5: 0 libSystem.B.dylib 0x91943afa mach_msg_trap + 10 1 libSystem.B.dylib 0x91944267 mach_msg + 68 2 com.apple.CoreFoundation0x95f5b2df __CFRunLoopRun + 2079 3 com.apple.CoreFoundation0x95f5a3c4 CFRunLoopRunSpecific + 452 4 com.apple.CoreFoundation0x95f60304 CFRunLoopRun + 84 5 com.apple.DesktopServices 0x947b1b3d TSystemNotificationTask::SystemNotificationTaskProc(void*) + 643 6 ...ple.CoreServices.CarbonCore 0x97ac554a PrivateMPEntryPoint + 68 7 libSystem.B.dylib 0x91971259 _pthread_start + 345 8 libSystem.B.dylib 0x919710de thread_start + 34 Thread 6: 0 libSystem.B.dylib 0x91969412 __workq_kernreturn + 10 1 libSystem.B.dylib 0x919699a8 _pthread_wqthread + 941 2 libSystem.B.dylib 0x919695c6 start_wqthread + 30 Thread 7: 0 libSystem.B.dylib 0x91969412 __workq_kernreturn + 10 1 libSystem.B.
[issue17523] Additional tests for the os module.
Will Weaver added the comment: It seems that I probably missed some tests as I only ran then on Mac OS. Such a minor addition so no need to do anything about it. If I go about it in a better way I'll make a new issue. -- resolution: -> wont fix status: open -> closed ___ Python tracker <http://bugs.python.org/issue17523> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29625] colorsys.rgb_to_hsv always returns saturation as 0 (python2.7.13 only)
New submission from Will Pittman: colorsys.rgb_to_hsv appears to be broken on python2.7.13 (on archlinux). Saturation is always reported as 0. ex: import colorsys rgb_to_hsv( 127, 116, 18 ) >>> (0.1, 0, 127) -- messages: 288380 nosy: Will Pittman priority: normal severity: normal status: open title: colorsys.rgb_to_hsv always returns saturation as 0 (python2.7.13 only) type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue29625> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29625] colorsys.rgb_to_hsv always returns saturation as 0 (python2.7.13 only)
Will Pittman added the comment: The bug appears to be caused by the difference in division symbols between python3 vs python2. The issue appears to be resolved if you add the following line to the `/usr/lib/python2.7.13/colorsys.py` module (or if all arguments are converted to floats). from __future__ import division I noticed that this bug persists all the back to at least python2.7.10 -- ___ Python tracker <http://bugs.python.org/issue29625> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29625] colorsys.rgb_to_hsv always returns saturation as 0 (python2.7 only)
Changes by Will Pittman : -- title: colorsys.rgb_to_hsv always returns saturation as 0 (python2.7.13 only) -> colorsys.rgb_to_hsv always returns saturation as 0 (python2.7 only) ___ Python tracker <http://bugs.python.org/issue29625> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29625] colorsys.rgb_to_hsv always returns saturation as 0 (python2.7 only)
Will Pittman added the comment: oh, thank you very much and sorry for my negligence! -- stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.python.org/issue29625> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27144] concurrent.futures.as_completed() memory inefficiency
Will Vousden added the comment: Is there a reason this hasn't been merged yet? Fixing this bug locally (albeit just by setting Future._result = None when I've extracted the result) reduced the memory footprint of my program from 50 GB to 7 GB, so it seems worth it. -- ___ Python tracker <http://bugs.python.org/issue27144> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17523] Additional tests for the os module.
New submission from Will Weaver: I've reorganized and added some os module tests. I split the makedirs tests into additional test methods that test one thing instead of a lot of different things. I added additional test coverage for a trailing '/'. I've also added the same test for removedirs. I reorganized the walk tests so that they actually run. Before there was only a setUp and a tearDown but no actual tests so the tests would not actually run. Lastly, I added tests for renames as there weren't any before. -- components: Tests files: mywork.patch keywords: patch messages: 184992 nosy: willweaver priority: normal severity: normal status: open title: Additional tests for the os module. type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file29549/mywork.patch ___ Python tracker <http://bugs.python.org/issue17523> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24809] Add getprotobynumber to socket module
New submission from Will Booth: Add an old method from netdb to python for a best-effort, centerized look up. For the function to work, /etc/protocols would also need to be present. If the protocol doesn't exist OSError is raised. Patch attached. -- components: Extension Modules files: proto.diff keywords: patch messages: 248128 nosy: wbooth priority: normal severity: normal status: open title: Add getprotobynumber to socket module type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file40137/proto.diff ___ Python tracker <http://bugs.python.org/issue24809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24809] Add getprotobynumber to socket module
Changes by Will Booth : -- versions: +Python 3.5 -Python 3.6 ___ Python tracker <http://bugs.python.org/issue24809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24809] Add getprotobynumber to socket module
Will Booth added the comment: Allow users to translate protocol numbers from IPv4/IPv6 headers to a friendly human readable string. Just filling a gap in the API. There might be a PyPI package out there similar to socket. However, it's complementary function,'getprotobyname', already exist here. getprotobynumber just flips getprotobyname around. -- ___ Python tracker <http://bugs.python.org/issue24809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25228] Regression in cookie parsing with brackets and quotes
Changes by Will Harris : -- nosy: +harris ___ Python tracker <http://bugs.python.org/issue25228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16098] Bisect optimization in heapq.nsmallest is never used
New submission from Will Haldean Brown: The implementation of nsmallest in heapq contains an optimization for when n is an order of magnitude less than the size of the data, which uses bisect to find the n-smallest elements. This optimization is guarded by a check to ensure that the data iterable has a length method. This method is then decorated to add support for the key kwarg. The decorator creates a zip object and passes the zip object to the decorated nsmallest. As zip objects are generators, they do not have a __len__ attribute, and the bisect optimization is never used. The attached patch file detects whether the data passed to the decorator has a length attribute, and if it does, it creates a list with the data before passing it to the decorated nsmallest. This is my first patch, so if I've done something wrong please let me know. Thanks! -- components: Library (Lib) files: heapq-use-bisect.20121001.patch keywords: patch messages: 171706 nosy: haldean priority: normal severity: normal status: open title: Bisect optimization in heapq.nsmallest is never used type: performance versions: Python 3.4 Added file: http://bugs.python.org/file27372/heapq-use-bisect.20121001.patch ___ Python tracker <http://bugs.python.org/issue16098> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16098] Bisect optimization in heapq.nsmallest is never used
Will Haldean Brown added the comment: Thanks for the clarification Raymond! -- resolution: -> invalid status: open -> closed ___ Python tracker <http://bugs.python.org/issue16098> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
