[issue46060] Clarify asyncio.new_event_loop return value
Change by Paul Bryan : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46060] Clarify asyncio.new_event_loop return value
Change by Paul Bryan : -- keywords: +patch nosy: +pbryan nosy_count: 2.0 -> 3.0 pull_requests: +28299 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30078 ___ Python tracker <https://bugs.python.org/issue46060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46060] Clarify asyncio.new_event_loop return value
New submission from Paul Bryan : Currently, the documentation states it creates a new event loop; it should also indicate that it returns the newly created event loop. -- assignee: docs@python components: Documentation messages: 408425 nosy: docs@python, pbryan2 priority: normal severity: normal status: open title: Clarify asyncio.new_event_loop return value versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue46060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1662] [patch] assert tp_traverse in PyType_GenericAlloc()
Bryan Silverthorn added the comment: I submitted this patch 14 years ago and am sure of nothing. :) -- ___ Python tracker <https://bugs.python.org/issue1662> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43345] Add __required_keys__ and __optional_keys__ to TypedDict documentation
Change by Paul Bryan : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43345> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43345] Add __required_keys__ and __optional_keys__ to TypedDict documentation
Change by Paul Bryan : -- keywords: +patch pull_requests: +23453 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24668 ___ Python tracker <https://bugs.python.org/issue43345> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43345] Add __required_keys__ and __optional_keys__ to TypedDict documentation
Change by Paul Bryan : -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue43345> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43345] Add __required_keys__ and __optional_keys__ to TypedDict documentation
New submission from Paul Bryan : >From Typing-sig list: On Thu, Feb 11, 2021 at 10:54 PM Paul Bryan wrote: > I don't think __required_keys__ or __optional_keys__ are documented, at least > not in https://docs.python.org/3.10/library/typing.html. Is there any reason > we can't codify them in 3.10 docs? On Fri, 2021-02-12 at 14:23 -0800, Guido van Rossum wrote: > Nobody got to it yet? Maybe you'd be willing to submit a small PR for this? -- assignee: docs@python components: Documentation messages: 387802 nosy: docs@python, pbryan priority: normal severity: normal status: open title: Add __required_keys__ and __optional_keys__ to TypedDict documentation versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43345> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42269] Add ability to set __slots__ in dataclasses
Change by Paul Bryan : -- nosy: +pbryan ___ Python tracker <https://bugs.python.org/issue42269> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33129] Add kwarg-only option to dataclass
Change by Paul Bryan : -- nosy: +pbryan ___ Python tracker <https://bugs.python.org/issue33129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42904] get_type_hints does not provide localns for classes
Change by Paul Bryan : -- nosy: +larry ___ Python tracker <https://bugs.python.org/issue42904> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42904] get_type_hints does not provide localns for classes
New submission from Paul Bryan : According to PEP 563: > The get_type_hints() function automatically resolves the correct value of > globalns for functions and classes. It also automatically provides the > correct localns for classes. This statement about providing correct localns for classes does not appear to be true. Guido suggested this should be treated as a bug. -- components: Library (Lib) messages: 384885 nosy: gvanrossum, pbryan priority: normal severity: normal status: open title: get_type_hints does not provide localns for classes type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42904> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42662] Propose: Data model explict about __annotations__ key ordering.
Paul Bryan added the comment: Retracting. -- resolution: -> not a bug stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42662> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42662] Propose: Data model explict about __annotations__ key ordering.
Change by Paul Bryan : -- keywords: +patch pull_requests: +22668 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23808 ___ Python tracker <https://bugs.python.org/issue42662> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42662] Propose: Data model explict about __annotations__ key ordering.
New submission from Paul Bryan : Currently the data model documentation does not specify the order of keys in __annotations__ dictionary. It is currently in the order that arguments or attributes are declared. I propose to make this explicit. Rationale: Having order explicitly specified in the documentation makes it a documented feature that code can depend on. Current code cannot safely rely on this behavior. -- assignee: docs@python components: Documentation messages: 383204 nosy: docs@python, pbryan priority: normal severity: normal status: open title: Propose: Data model explict about __annotations__ key ordering. versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42662> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42592] TypedDict: total=False but still key required
Paul Bryan added the comment: Your patch LGTM, Brandt. -- ___ Python tracker <https://bugs.python.org/issue42592> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42592] TypedDict: total=False but still key required
New submission from Paul Bryan :
I believe "a" below should be an optional key, not a required one.
Python 3.9.0 (default, Oct 7 2020, 23:09:01)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import typing
>>> TD = typing.TypedDict("TD", {"a": str}, total=False)
>>> TD.__total__
False
>>> TD.__required_keys__
frozenset({'a'})
>>> TD.__optional_keys__
frozenset()
>>>
--
components: Library (Lib)
messages: 382662
nosy: gvanrossum, pbryan
priority: normal
severity: normal
status: open
title: TypedDict: total=False but still key required
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue42592>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16830] Add skip_host and skip_accept_encoding to HTTPConnection.request()
Bryan Bishop added the comment: I'll go ahead and close this. The putrequest/putheader/endheaders suggestion is probably sufficient. Although I do wonder if a docs update is warranted, explaining the default behavior.. -- resolution: -> wont fix stage: -> resolved status: pending -> closed ___ Python tracker <https://bugs.python.org/issue16830> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32113] Strange behavior with await in a generator expression
Change by Bryan Hu : -- versions: +Python 3.8 ___ Python tracker <https://bugs.python.org/issue32113> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41087] Argparse int / float default
Bryan added the comment: So you agree, Python lacks common sense... On Wed, 24 Jun 2020 at 03:32, Vedran Čačić wrote: > > Vedran Čačić added the comment: > > Yes, it is common sense in statically typed languages. Python is not > statically typed. Many other things are also "common sense" in various > paradigms, which doesn't mean they should also be in Python. > > -- > nosy: +veky > > ___ > Python tracker > <https://bugs.python.org/issue41087> > ___ > -- ___ Python tracker <https://bugs.python.org/issue41087> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41087] Argparse int / float default
Bryan added the comment: This sort of ambiguity is why I like strongly typed languages and languages where timtoady is not seen often. I can guarantee you, that if argparse was implemented in Pascal (and copt most probably has been), that if type was specified and a default given, that the default would have to adhere to that type. It is just programming common sense On Wed, 24 Jun 2020 02:20 paul j3, wrote: > > paul j3 added the comment: > > No, parameters like `type` let the developer control what his users > provides. Violating that produces a runtime error, and exit. > > But in general argparse does not try to control values that the developer > uses. There's plenty of time during development to catch error such as > this - if they are errors at all. > > 'type' does not 'declare' what the attribute will be. It is a function > that is applied to the input string, and converts that to something or > other, or raises a TypeError. It is used only if there is a string value > to work on, either from the user, or a string default. > > This is not a bug, so should be closed. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue41087> > ___ > -- ___ Python tracker <https://bugs.python.org/issue41087> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41087] Argparse int / float default
Bryan added the comment: Maybe so, But, the issue is, if it trips up a user when they try to use the option, it should trip up the dev when the default is used... On Tue, 23 Jun 2020 18:47 Karthikeyan Singaravelan, wrote: > > Karthikeyan Singaravelan added the comment: > > There is a documentation note on type casting along with an example > similar to the report > https://docs.python.org/3.8/library/argparse.html#default > > > If the default value is a string, the parser parses the value as if it > were a command-line argument. In particular, the parser applies any type > conversion argument, if provided, before setting the attribute on the > Namespace return value. Otherwise, the parser uses the value as is: > > -- > nosy: +paul.j3, rhettinger, xtreak > type: -> behavior > > ___ > Python tracker > <https://bugs.python.org/issue41087> > ___ > -- ___ Python tracker <https://bugs.python.org/issue41087> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41087] Argparse int / float default
New submission from Bryan :
parser.add_argument('-e', '--Edge', type = int, default = 0.005, metavar =
'Edge')
Runs fine. Script uses default of 0.005 even when int specified.
But if user tries to change, not an int
--
messages: 372143
nosy: Bryan
priority: normal
severity: normal
status: open
title: Argparse int / float default
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue41087>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35756] Using `return value` in a generator function skips the returned value on for-loop iteration
New submission from Bryan Koch : Using the new "`return value` is semantically equivalent to `raise StopIteration(value)`" syntax created in PEP-380 (https://legacy.python.org/dev/peps/pep-0380/#formal-semantics) causes the returned value to be skipped by standard methods of iteration. The PEP reads as if returning a value via StopIteration was meant to signal that the generator was finished and that StopIteration.value was the final value. If StopIteration.value is meant to represent the final value, then the built-in for-loop should not skip it and the current implementation in 3.3, 3.4, 3.5, and 3.6 should be considered an oversight of the PEP and a bug (I don't have a version of 3.7 or 3.8 to test newer versions). Reproduction code is attached with comments/annotations. -- files: ex1.py messages: 333802 nosy: Bryan Koch priority: normal severity: normal status: open title: Using `return value` in a generator function skips the returned value on for-loop iteration type: behavior versions: Python 3.4, Python 3.5, Python 3.6 Added file: https://bugs.python.org/file48062/ex1.py ___ Python tracker <https://bugs.python.org/issue35756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31453] Debian Sid/Buster: Cannot enable TLS 1.0/1.1 with PROTOCOL_TLS
bryan mabra added the comment: FYI, This is how I figured out and fixed the issue on my debian system. -Run nmap to figure out what ssl version is being used by the server nmap -p443 -sV --script ssl-enum-ciphers 10.10.10.7 output says TLSv1.0 test 10.10.10.7 using example in this comment (gets expected error) https://github.com/requests/requests/issues/606#issuecomment-8036266 test with openssl binary (gets expected error) openssl s_client -connect 10.10.10.7:443 fix by editing this value-->MinProtocol = TLSv1.0 in this file--> /etc/ssl/openssl.cnf rerun tests without error. Note the outdated server I am connecting to is internal, non-production, not connected to the internet. -- nosy: +mabrafoo ___ Python tracker <https://bugs.python.org/issue31453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34608] gc.get_referrers behavior change 3.6 to 3.7
New submission from Bryan :
When called on a local object inside a function, gc.get_referrers no longer
returns a Frame as one of the references. I could not find anything in the
release notes or changeling that indicated that this is an intentional change.
The following script generates different output when run on Python 3.6 vs
Python 3.7 (on linux, OSX, or Windows):
```
# referrers.py
import gc, sys
class FakeMod(object): pass
extra = []
def test():
mod = FakeMod()
extra.append(mod)
referrers = gc.get_referrers(mod)
print(".".join(str(x) for x in sys.version_info[:3]), ":", len(referrers),
referrers)
test()
```
Output:
~ master*
(py37) ❯ python test.py
3.7.0 : 1 [[<__main__.FakeMod object at 0x10b65e320>]]
~ master*
(base) ❯ python test.py
3.6.6 : 2 [[<__main__.FakeMod object at 0x106f3ea90>], ]
--
components: Library (Lib)
messages: 324771
nosy: bryevdv
priority: normal
severity: normal
status: open
title: gc.get_referrers behavior change 3.6 to 3.7
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue34608>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28695] Add SSL_CTX_set_client_cert_engine
Change by Bryan Hunt : -- nosy: +bryguy ___ Python tracker <https://bugs.python.org/issue28695> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31652] make install fails: no module _ctypes
Bryan added the comment:
Similar error on CentOS 7
ModuleNotFoundError: No module named '_ctypes'
Install -- yum install libffi-devel
Repeat:
./configure --enable-optimizations
make altinstall
Results:
Collecting setuptools
Collecting pip
Installing collected packages: setuptools, pip
Successfully installed pip-10.0.1 setuptools-39.0.1
NOTE:
The error did not stop python3.7 from operating as noted on this page.
# python3.7
Python 3.7.0 (default, Jul 16 2018, 11:25:12)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-28)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> print ("Hello Python")
Hello Python
>>>
--
nosy: +bryanf
___
Python tracker
<https://bugs.python.org/issue31652>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33289] tkinter askcolor returning floats for r, g, b values instead of ints
Bryan Oakley added the comment: yes, this is a well known backwards incompatibility. In python 2, the division operator returns an integer if both operands are integers. In python 3 it returns a float. https://www.python.org/dev/peps/pep-0238/ On Thu, Jul 12, 2018 at 8:48 AM STINNER Victor wrote: > > STINNER Victor added the comment: > > Is this issue a regression of Python 3? red/256 gave an integer on Python > 2? > > -- > nosy: +vstinner > > ___ > Python tracker > <https://bugs.python.org/issue33289> > ___ > -- title: tkinter askcolor returning floats for r,g,b values instead of ints -> tkinter askcolor returning floats for r, g, b values instead of ints ___ Python tracker <https://bugs.python.org/issue33289> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33289] askcolor is returning floats for r, g, b values instead of ints
New submission from Bryan Oakley <bryan.oak...@gmail.com>: Even though the underlying tcl/tk interpreter is returning ints, askcolor is converting the values to floats. My guess is this is an oversight related to the change in functionality of the / operator in python3. this: return (r/256, g/256, b/256), str(result) should probably be this: return (r//256, g//256, b//256), str(result) -- components: Tkinter messages: 315367 nosy: Bryan.Oakley priority: normal severity: normal status: open title: askcolor is returning floats for r,g,b values instead of ints versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33289> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29960] _random.Random state corrupted on exception
Changes by Bryan G. Olson <bryan.ol...@acm.org>: -- pull_requests: +1181 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29960> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29960] _random.Random state corrupted on exception
Changes by Bryan G. Olson <bryan.ol...@acm.org>: -- pull_requests: +1135 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29960> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29960] _random.Random state corrupted on exception
Bryan G. Olson added the comment: I'm going through https://docs.python.org/devguide/pullrequest.html and would like to be assigned this issue. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29960> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29960] _random.Random state corrupted on exception
New submission from Bryan G. Olson: Demo: Run the Python library's test_random.py under the Python debugger and check the generator at the start of test_shuffle(): C:\bin\Python36>python -m pdb Lib\test\test_random.py > c:\bin\python36\lib\test\test_random.py(1)() -> import unittest (Pdb) break 61 Breakpoint 1 at c:\bin\python36\lib\test\test_random.py:61 (Pdb) continue .> c:\bin\python36\lib\test\test_random.py(61)test_shuffle() -> shuffle = self.gen.shuffle (Pdb) list 56 # randomness source is not available. 57 urandom_mock.side_effect = NotImplementedError 58 self.test_seedargs() 59 60 def test_shuffle(self): 61 B-> shuffle = self.gen.shuffle 62 lst = [] 63 shuffle(lst) 64 self.assertEqual(lst, []) 65 lst = [37] 66 shuffle(lst) (Pdb) p self.gen.getrandbits(31) 2137781566 (Pdb) p self.gen.getrandbits(31) 2137781566 (Pdb) p self.gen.getrandbits(31) 2137781566 (Pdb) p self.gen.getrandbits(31) 2137781566 (Pdb) p self.gen.getrandbits(31) 2137781566 That's not random. Diagnosis: The order in which test functions run is the lexicographic order of their names. Thus unittest ran test_setstate_middle_arg() before running test_shuffle(). test_setstate_middle_arg() did some failed calls to _random.Random.setstate(), which raised exceptions as planned, but also trashed the state of the generator. test_random.py continues to use the same instance of _random.Random after setstate() raises exceptions. The documentation for Random.setstate() does not specify what happens to the state of the generator if setstate() raises an exception. Fortunately the generator recommended for secure applications, SystemRandom, does not implement setstate(). Solution: The fix I prefer is a small change to random_setstate() in _randommodule.c, so that it does not change the state of the generator until the operation is sure to succeed. -- components: Library (Lib) messages: 290977 nosy: bryangeneolson priority: normal severity: normal status: open title: _random.Random state corrupted on exception type: behavior versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29960> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26296] colorsys rgb_to_hls algorithm error
Bryan B added the comment: Well, the other issue was resolved by updating Python on my computer to 3.6 ;) Setting up the entire Python build and test environment for an issue this small seems a little excessive, especially for a module that seems seldomly used. I'm gonna have to be that guy and let this one sit as well. Sorry :( -- title: colorys rgb_to_hls algorithm error -> colorsys rgb_to_hls algorithm error ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26296> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26296] colorys rgb_to_hls algorithm error
Bryan B added the comment: Adding myself to this since I'm going to fix another hiccup in this file and I might as well clean this up too. -- nosy: +aarqon ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26296> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28711] IDLE doesn't open
New submission from Bryan: Hello there I am using python 2.7 on windows 10 because my college class requires it, I am having issues when trying to open the IDLE. When i click on it the blue ring loads and then noting happens. I started to have to issue when i was changing the key settings so i can right- click or at least trying to figure out how to do it. If anyone can help it will greatly appreciated. -- messages: 280910 nosy: bg90299 priority: normal severity: normal status: open title: IDLE doesn't open type: behavior versions: Python 2.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28711> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25684] ttk.OptionMenu radiobuttons aren't unique between two instances of OptionMenu
Changes by Bryan Oakley <bryan.oak...@gmail.com>: -- type: -> behavior ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25684> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25684] ttk.OptionMenu radiobuttons aren't unique between two instances of OptionMenu
New submission from Bryan Oakley: Original issue was brought to my attention by this SO question: http://stackoverflow.com/questions/33831289/ttk-optionmenu-displaying-check-mark-on-all-menus The ttk.OptionMenu uses radiobuttons for the dropdown menu. However, because it doesn't set the `variable` attribute, they all get the default. If you have two or more OptionMenu instances, all of the radiobuttons are tied together. If you select the first item in the first OptionMenu, and the second item in the second OptionMenu, the dropdown menu for both will show the second item checked. The solution is to add `variable=self._variable` when creating the menu radiobutton items. -- components: Tkinter messages: 255001 nosy: Bryan.Oakley priority: normal severity: normal status: open title: ttk.OptionMenu radiobuttons aren't unique between two instances of OptionMenu versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25684> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24732] 3.5.0b3 Windows accept() on unready non-blocking socket raises PermissionError
New submission from Bryan G. Olson:
In Python 3.4 on Windows 7, the code:
import socket
sock = socket.socket()
sock.bind(('127.0.0.1', 52384))
sock.listen(5)
sock.setblocking(False)
csock, addr = sock.accept()
Raised:
Traceback (most recent call last):
File socket_bug_test.py, line 8, in module
csock, addr = sock.accept()
File c:\bin\Python34\lib\socket.py, line 187, in accept
fd, addr = self._accept()
BlockingIOError: [WinError 10035] A non-blocking socket operation could not
be completed immediately
In Python 3.5.0b3 on the same system, it is raising:
Traceback (most recent call last):
File socket_bug_test.py, line 8, in module
csock, addr = sock.accept()
File c:\bin\Python35\lib\socket.py, line 195, in accept
fd, addr = self._accept()
PermissionError: [WinError 5] Access is denied
This is a problem for other parts of the Standard Library. I hit it playing
with asyncio, where in Lib\asyncio\selector_events.py the function
BaseSelectorEventLoop._sock_accept() is prepared for an unready socket to raise
BlockingIOError or InterruptedError, but does not catch the WinError:
try:
conn, address = sock.accept()
conn.setblocking(False)
except (BlockingIOError, InterruptedError):
self.add_reader(fd, self._sock_accept, fut, True, sock)
except Exception as exc:
fut.set_exception(exc)
else:
fut.set_result((conn, address))
There are other calls to accept in accept() in asyncio, that I haven't tested
but also look adversely affected.
The older asyncore module looks to have a similar problem. In
dispatcher.accept():
def accept(self):
# XXX can return either an address pair or None
try:
conn, addr = self.socket.accept()
except TypeError:
return None
except OSError as why:
if why.args[0] in (EWOULDBLOCK, ECONNABORTED, EAGAIN):
return None
else:
raise
else:
return conn, addr
The 'except OSError as why' will catch the WinError, but why.args[0] will be
errno.EACCES = 13, permission denied, which is not equal to any of anticipated
errors.
My system according to Python:
import sys
sys.version
'3.5.0b3 (default, Jul 5 2015, 07:00:46) [MSC v.1900 64 bit (AMD64)]'
sys.getwindowsversion()
sys.getwindowsversion(major=6, minor=1, build=7601, platform=2,
service_pack='Service Pack 1')
That's Windows 7 Professional, 64-bit, with Service pack 1. It has an AND
Phenom II X6 1055T Processor 2.8 GHz, and 8GB of memory.
--
components: Windows
messages: 247452
nosy: bryangeneolson, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: 3.5.0b3 Windows accept() on unready non-blocking socket raises
PermissionError
type: behavior
versions: Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24732
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] datetime: add ability to parse RFC 3339 dates and times
Changes by Paul Bryan pbr...@anode.ca: -- nosy: +pbryan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15873 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17010] Windows launcher ignores active virtual environment
New submission from Bryan G. Olson: Python 3.3 includes PEP 397, a Python launcher for Windows, and PEP 405, virtual environment support in core. Unfortunately the Windows launcher does not respect virtual environments. Even with with a virtual environment activated and the current directory at the virtual environment's root, the Windows launcher will start python with the system environment, not the active virtual environment. To demo: Install python 3.3 for windows. Create a virtual environment: C:\c:\Python33\Tools\Scripts\pyvenv.py c:\virtpy Activate the virtual environment: C:\virtpy\Scripts\activate.bat (virtpy) C:\ Optionally cd to the virtual environment: (virtpy) C:\cd virtpy (virtpy) C:\virtpy Start Python 3 with the new windows launcher: (virtpy) C:\virtpypy -3 Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. Check sys.path import sys sys.path ['', 'C:\\Windows\\system32\\python33.zip', 'C:\\bin\\Python33\\DLLs', 'C:\\bin\\Python33\\lib', 'C:\\bin\\Python33', 'C:\\bin\\Python33\\lib\\site-packages'] The worst effect I've found is that installation of a package with windows launcher, py -3 setup.py install, will ignore the active virtual environment and will change the system Python environment. That's bad because users frequently employ virtual environments to isolate changes that could damage a system configuration. -- components: Installation, Windows messages: 180362 nosy: bryangeneolson priority: normal severity: normal status: open title: Windows launcher ignores active virtual environment type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17010 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16830] Add skip_host and skip_accept_encoding to httplib/http.client
Bryan Bishop added the comment:
On Tue, Jan 1, 2013 at 5:41 AM, Antoine Pitrou wrote:
Another possibility would be to allow passing None in values of the `headers`
dict, in which case the given header wouldn't be send at all.
I agree that your solution is more scaling-friendly than the patch I originally
submitted. But from another perspective, consider how alien it is to have to
explicitly add keys set to None in the headers to get desired behavior.
Maybe there could be a single flag strict (or possibly a better name) that
would indicate that the dict is in fact what I want to send and that it should
not be modified? Or perhaps there should be base_headers list (not a
dictionary) of header keys of which defaults to not inject?
Also, would making {Accept-Encoding: None} send no Accept-Encoding header
be backwards incompatible with the current behavior?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16830
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16830] Add skip_host and skip_accept_encoding to httplib/http.client
New submission from Bryan Bishop: Sometimes I am using httplib/http.client and the server is not exactly conforming to HTTP specs. I need to be able to specify the exact headers that are sent to the server. By default, httplib/http.client injects headers like Host and Accept-Encoding. Issue #831747 added skip_accept_encoding to httplib's putrequest method, but not on the request method. This current patch exposes these two toggles on the request method. This way, headers can be controlled without manually calling the connect/send/endheaders methods. As a result, urllib/urllib3 can call urlopen and pass in these attributes to more directly control the headers sent to the remote server. -- components: Library (Lib) files: httplib_better_header_skips.patch keywords: patch messages: 178719 nosy: kanzure priority: normal severity: normal status: open title: Add skip_host and skip_accept_encoding to httplib/http.client type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file28516/httplib_better_header_skips.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16830 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15861] ttk.Treeview unmatched open brace in list
Bryan Oakley added the comment:
I gave myself an hour or so to play around with this, and the crux of the
matter seems to be in the function `_format_optdict()` which converts a
dictionary of options and values into something suitable to pass to
`tk.call()`. However, I think the same bug is in other `_format*` functions as
well, it's just that their nature is such that they have much less of a chance
to be passed weird data.
`_format_optdict` has some code that does a half-hearted attempt at handling
values that are tuples, such as the case with the values attribute of the
ttk.Treeview widget. However, all it does is protect values that have a space,
by surrounding the value with curly braces. Hence, when the value itself has a
curly brace, tcl throws the unmatched open brace error.
What is needed is to create a bona fide tcl list element according to the rules
of Tcl. I tried a hack where I simply escaped all problem characters, so
instead of returning `{foo bar}` the function returns `foo\ bar`. This seemed
to work, at least for the tiny bit of testing that I did. Another solution
might be to do something like tk.call(list,*the_tuple), though sadly,
`_format_optdict` is a function rather than a method so it doesn't have access
to the tcl interpreter.
What I think ttk needs (and may already exist somewhere in the Tkinter world; I
haven't looked...) is a function that takes a tuple and converts it to a
canonical list. Then, the places that do something ad hoc can all call this one
function.
For more information on the gory details of the string representation of a list
see http://www.tcl.tk/cgi-bin/tct/tip/407.html
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15861
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15861] ttk.Treeview unmatched open brace in list
Bryan Oakley added the comment:
What behavior do I expect? I expect it to not throw an error. I expect whatever
string I give to be inserted into the widget unadulterated (ie: if I give the
string foo { I expect to see foo { in the widget).
Tkinter is effectively telling me you have a Tcl syntax error. Since I'm
programming in python I should be insulated from that, particularly since the
error comes internally after Tkinter transforms my data.
How Tkinter does it under the hood, I don't care. Tkinter should make sure that
the data it passes to the Tcl interpreter is well-formed.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15861
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15861] ttk.Treeview unmatched open brace in list
New submission from Bryan Oakley:
If you try to insert an item into the treeview, give it a tuple of values for
the values attribute, and one of those values has unbalanced braces, you'll
get an error unmatched open brace in list
To reproduce:
import Tkinter as tk
import ttk
root = tk.Tk()
tree = ttk.Treeview(root)
tree.insert(,end,values=(one,two,bam! {))
root.mainloop()
--
components: Tkinter
messages: 169839
nosy: Bryan.Oakley
priority: normal
severity: normal
status: open
title: ttk.Treeview unmatched open brace in list
type: behavior
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15861
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13345] Invisible Files in Windows 7
Jon Bryan jrbr...@sandia.gov added the comment: Thanks for the suggestions. Since I can put the OEM-supplied DLL in another directory and everything works just fine, I'm not going to spend any more time on it. I assume that it's something to do with file permissions in Win7 that I don't have any inclination to delve into further. And I can always run it on my old laptop if I have to. === Jon -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13345 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13345] Invisible Files in Windows 7
New submission from Jon Bryan jrbr...@sandia.gov: Running 32-bit Python in 64-bit Windows 7 Enterprise. I am very much a Python noob. A .dll in c:\Windows\System32 that I need to access can't be found by ctypes.WinDLL(). Upon further investigation I have found that the file, along with many others, doesn't show up in an os.listdir() either. Within IDLE the files don't appear in the drop-down autocomplete list. I don't have this problem on either of the Windows XP machines I've tried it on, but in Win7 I see the same behavior in both 2.7 and 3.2. -- components: IDLE, Windows, ctypes messages: 147052 nosy: jrbryan priority: normal severity: normal status: open title: Invisible Files in Windows 7 type: behavior versions: Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13345 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12353] argparse cannot handle empty arguments
New submission from Bryan Jacobs bjac...@woti.com:
Parsing arguments with argparse fails with an IndexError when one of the
arguments is the empty string (''). This is caused by an access to the zero'th
element of the argument value, without a preceding length check.
Fixed by the below patch:
Index: Lib/argparse.py
===
--- Lib/argparse.py
+++ Lib/argparse.py
@@ -1967,7 +1967,7 @@ class ArgumentParser(_AttributeHolder, _
for arg_string in arg_strings:
# for regular arguments, just add them back into the list
-if arg_string[0] not in self.fromfile_prefix_chars:
+if len(arg_string) == 0 or arg_string[0] not in
self.fromfile_prefix_chars:
new_arg_strings.append(arg_string)
# replace arguments referencing files with the file content
--
components: Library (Lib)
messages: 138515
nosy: bjacobs
priority: normal
severity: normal
status: open
title: argparse cannot handle empty arguments
type: behavior
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12353
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1590864] Function-level import in os triggering an threaded import deadlock
Bryan Schmersal bryan.schmer...@gmail.com added the comment: I have a module that I was using on 2.5 that uses subprocess.Popen to monitor the output from some external programs in several different threads. Of course, subprocess.Popen uses os.fork. When I upgraded to 2.7 which includes this fix, this module ran into a deadlock since the fork is being executed from within an import. One could argue that my approach is poor style but one of the goals of this module is simplicity for the usersthey simply need to import it to get the functionality of the module. Was this a desired side-effect? -- nosy: +Bryan.Schmersal ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1590864 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8979] OptParse __getitem__
Bryan Ward bwa...@gmail.com added the comment: Thanks for your help and I apologize for the unnecessary ticket. I was unfamiliar with vars() which seems to accomplish what I wanted. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8979 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8979] OptParse __getitem__
New submission from Bryan Ward bwa...@gmail.com: It would be convenient to be able to access the resultant options from optparse using the syntax options['some_option'] instead of options.some_option Or additionally it would be nice to have a way to produce a dictionary of the options. This would be nice to have to do something to the effect of dictOptions = options.to_dict() obj = SomeObject(**dictOptions) -- components: Extension Modules messages: 107620 nosy: bcward priority: normal severity: normal status: open title: OptParse __getitem__ type: feature request versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8979 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7689] Pickling of classes with a metaclass and copy_reg
Changes by Bryan Silverthorn bc...@cornell.edu: -- nosy: +bsilverthorn ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7689 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6802] build fails on Snow Leopard
Bryan Blackburn b...@users.sourceforge.net added the comment: The patch has one issue in the added AC_TRY_RUN ( http://svn.python.org/view/python/trunk/configure.in? annotate=74672pathrev=74672#l1542 ): it doesn't like the two [[...]] and main() needs a closing brace, }. Otherwise, it fails on 10.5.8 (Xcode 3.1.3, Intel) to properly detect 32bit vs 64bit (and if you look at config.log you should see complaints from around line 7065). Attaching a patch which fixes it here. -- Added file: http://bugs.python.org/file14851/configure.in.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6802] build fails on Snow Leopard
Changes by Bryan Blackburn b...@users.sourceforge.net: -- nosy: +blb ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1662] [patch] assert tp_traverse in PyType_GenericAlloc()
Bryan Silverthorn bc...@cornell.edu added the comment: Well, there's no Python bug per se, hence no test case; this patch just adds a single additional assert that might catch a particular extension implementation mistake. It was prompted by tracking down the bug in pygtk mentioned above. I've attached an updated patch against r72055. It's a trivial change, but I would suggest that someone more familiar with the Python core sign off on it regardless. -- Added file: http://bugs.python.org/file13800/bcs_assert_tp_traverse_r72055.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1662 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1662] [patch] assert tp_traverse in PyType_GenericAlloc()
Changes by Bryan Silverthorn bc...@cornell.edu: Removed file: http://bugs.python.org/file8998/bcs_typeobject_assert.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1662 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5766] Mac/scripts/BuildApplet.py reset of sys.executable during install can cause it to use wrong modules
Bryan Blackburn b...@users.sourceforge.net added the comment: FYI, I'm able to avoid this by using PYTHONHOME=$(DESTDIR)$(prefix) before $(RUNSHARED) when running BuildApplet.py and $(BUNDLEBULDER) in Mac/Makefile.in, Mac/IDLE/Makefile.in, and Mac/PythonLauncher/Makefile.in. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5766 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5766] Mac/scripts/BuildApplet.py reset of sys.executable during install can cause it to use wrong modules
New submission from Bryan Blackburn b...@users.sourceforge.net: With Python 2.6.1 currently installed and attempting to install 2.6.2 into a DESTDIR location, and having a different configuration for the new one (2.6.1 built with default Unicode settings, 2.6.2 with UCS4), BuildApplet.py fails because of symbol not found. Full output (building with MacPorts, hence the sometimes-funky paths) attached as a text file. -- components: Installation, Macintosh files: python262_error.txt messages: 86009 nosy: blb severity: normal status: open title: Mac/scripts/BuildApplet.py reset of sys.executable during install can cause it to use wrong modules type: compile error versions: Python 2.6 Added file: http://bugs.python.org/file13695/python262_error.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5766 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4017] IDLE 2.6 broken on OSX (Leopard)
Bryan Bingham [EMAIL PROTECTED] added the comment: Installing tcl 8.5 from activestate gets rid of that error but then the following happens on my pretty clean iMac: Traceback (most recent call last): File /usr/local/bin/idle, line 5, in module main() File /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/idlelib /PyShell.py, line 1382, in main root = Tk(className=Idle) File /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib- tk/Tkinter.py, line 1645, in __init__ self._loadtk() File /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib- tk/Tkinter.py, line 1659, in _loadtk % (_tkinter.TK_VERSION, tk_version) RuntimeError: tk.h version (8.4) doesn't match libtk.a version (8.5) -- nosy: +ohmi ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4017 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1662] [patch] assert tp_traverse in PyType_GenericAlloc()
New submission from Bryan Silverthorn:
Attached is a very short patch against r59568 which asserts tp_traverse
on (the types of) objects allocated in PyType_GenericAlloc(). As far as
I'm aware, tp_traverse should always be set at this point. Catching that
error early, even if only in debug builds, would help to prevent bugs
like http://bugzilla.gnome.org/show_bug.cgi?id=504337 .
--
components: Interpreter Core
files: bcs_typeobject_assert.patch
messages: 58811
nosy: bsilverthorn
severity: minor
status: open
title: [patch] assert tp_traverse in PyType_GenericAlloc()
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file8998/bcs_typeobject_assert.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1662
__Index: Objects/typeobject.c
===
--- Objects/typeobject.c (revision 59568)
+++ Objects/typeobject.c (working copy)
@@ -469,8 +469,10 @@
else
(void) PyObject_INIT_VAR((PyVarObject *)obj, type, nitems);
- if (PyType_IS_GC(type))
+ if (PyType_IS_GC(type)) {
+ assert(type-tp_traverse);
_PyObject_GC_TRACK(obj);
+ }
return obj;
}
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1191] Berkeley DB prerequisite inconsistent
New submission from Bryan Henderson: There's some inconsistency among the code and documentation as to the required level of Berkeley DB. I don't know what the proper resolution, but I'm sure someone familiar with the history of this code does. Something needs to be done to reduce the amount of time it takes someone (as it did me) to deal with not having the expected level of Berkeley DB installed. I attached a file with a detailed explanation of my observations. -- components: Build files: problem_description.txt messages: 56093 nosy: giraffedata severity: normal status: open title: Berkeley DB prerequisite inconsistent type: compile error versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1191 __The Python manual for module 'bsddb'says it requires a Berkeley DB library 3.3 - 4.4. But the build tools do not check this. If that's the requirement, they should. Instead, I see in _bsddb.c lots of code explicitly intended for Berkeley DB 3.3. If this code is dead, it probably should be cleaned out, and whether it is cleaned out or not, comments in _bsddb.c should indicate what its Berkeley DB level requirement is (and why). Indeed, _bsddb.c does not compile for Berkeley DB 3.1 (at least as installed on my system). That's because it refers to macro DB_FAST_STAT even though it does not exist in Berkeley DB before Release 3.3. However, other parts of the code are designed to handle the absence of DB_FAST_STAT in older Berkeley DB, so I just put the appropriate if (DBVER = 33) in and it compiled. The next inconsistency is that the 'dbhash' module insists, at run time, on Berkeley DB version 3.2 or better. If 'bsddb' must have at least 3.3, then this check is superfluous. A bigger problem is that the error message it gives when you don't have 3.2 or better is the misleading, correct BerkeleyDB symbols not found. What would be better is, You have Berkeley DB 3.1. You need at least 3.2. FWIW, I removed the check and 'dbhash' worked for my purposes with Berkeley DB 3.1. Maybe the documented 3.3 prerequisite is too strong, and it should be more specific about what doesn't work with older versions. This all comes from Python 2.5. ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
