Tim Tisdall added the comment:
Okay, since there's currently no existing tests for the Bluetooth components of
socket and the only example for BDADDR_ALL seems to be for something I'm not
sure you can do in socket, I'm just going to not bother including it.
I've attached a 3.6 patch without
Tim Tisdall added the comment:
okay, I talked to one of the Bluez developers and he recommended leaving out
BDADDR_ALL since it doesn't seem to correspond to anything in the kernel.
--
___
Python tracker <rep...@bugs.python.org>
Changes by Tim Tisdall <tisd...@gmail.com>:
Added file: http://bugs.python.org/file40426/bdaddr_35_1.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Tim Tisdall added the comment:
Yes, then any existing implementations will continue to work.
One sticky issue with all of this... there's no existing tests as per #7687 .
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Tim Tisdall added the comment:
oops. yeah, I got my terminology wrong. It accepts only a byte-string.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Tim Tisdall <tisd...@gmail.com>:
--
keywords: +patch
Added file: http://bugs.python.org/file40424/bdaddr_36_1.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Tim Tisdall <tisd...@gmail.com>:
Added file: http://bugs.python.org/file40425/bdaddr_34_1.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Tim Tisdall <tisd...@gmail.com>:
--
versions: +Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue7687>
___
_
Tim Tisdall added the comment:
I'm not sure how to unit test a constant... it's just a string. If you're
asking for a unit test for when you'd actually make use of the constant, I
haven't been able to figure out that situation yet. It seems like in Bluez
4.101 it's used to issue a command
New submission from Tim Tisdall:
When Bluetooth LE support was added to Bluez they expanded sockaddr_l2 (the
struct for making L2CAP connections) to include a l2_bdaddr_type. Since the
existing code initializes the struct with 0's the type is set to regular
Bluetooth (BDADDR_BREDR
New submission from Tim Tisdall:
As mentioned in #24984, I'm making another issue to document the address format
for AF_PACKET. In this case there's already documentation in
Modules/socketmodule.c that says:
- an AF_PACKET socket address is a tuple containing a string
specifying
Tim Tisdall added the comment:
Right now the docs say "Certain other address families (:const:`AF_PACKET`,
:const:`AF_CAN`) support specific representations.".
I was going to create a separate issue for AF_CAN, but it seems that it's
already documented... When documentatio
Tim Tisdall added the comment:
I created #25041 to handle AF_PACKET. It seems AF_CAN is already in the docs,
so the person making the change for AF_PACKET can just remove that mention of
AF_CAN farther down.
--
___
Python tracker <
New submission from Tim Tisdall:
further to #24984, I noticed there are constants that aren't mentioned in the
docs. Also BDADDR_ALL is missing (which is defined in Bluez's bluetooth.h) so
I added it.
Now, I'm not totally clear on supplying multi-version patches... I know 3.5 is
in "f
Changes by Tim Tisdall <tisd...@gmail.com>:
--
components: +Extension Modules
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Tim Tisdall:
All of the BTPROTO_ protocols accept tuples with Bluetooth addresses as regular
strings. SCO accepts a byte-string which represents a Bluetooth address. The
change was made at 23ab586c427a
With the current implementation we get this error:
>>&g
Tim Tisdall added the comment:
Martin, looks good. Thanks for pointing out how to properly tag the version
change, and thanks for adding me to the ACKS file.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Tim Tisdall added the comment:
I'm not really sure how to add a `versionadded` tag to specify that only the
BSD-specific support was added in 3.2 (as general support was there prior to
that). If I just add the plain tag below that bullet point it would imply that
the whole protocol was added
Tim Tisdall added the comment:
I added a note to BTPROTO_SCO that it doesn't work in FreeBSD (I forgot to
mention that).
--
Added file: http://bugs.python.org/file40341/bluetooth_socket_docs_3.patch
___
Python tracker <rep...@bugs.python.org>
Tim Tisdall added the comment:
I'm not sure the proper way to update the patch... I can't seem to edit the
existing one or replace it. I'm uploading an updated one, but should I simply
"unlink" (aka delete) the old one?
--
Added file: http://bugs.python.org
Tim Tisdall added the comment:
Martin, the odd thing with the SCO protocol is it's expecting an bluetooth
address as a byte string (ex b'12:23:34:45:56:67' [note the `b`]) where the
other 3 are expecting a regular string (ex '12:23:34:45:56:67'). I think it
may have been a case of someone
Tim Tisdall added the comment:
changed "This protocol does not work under FreeBSD." to the more accurate "This
protocol is not supported under FreeBSD."
--
Added file: http://bugs.python.org/file40343/bluetooth_socket_docs_4.patch
__
New submission from Tim Tisdall:
Currently https://docs.python.org/3.6/library/socket.html#socket-families only
says "Certain other address families (AF_BLUETOOTH, AF_PACKET, AF_CAN) support
specific representations." and there's a comment in the docs saying "document
the
Changes by Tim Tisdall tisd...@gmail.com:
--
nosy: +Tim.Tisdall
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7687
___
___
Python-bugs-list
Changes by Tim Tisdall tisd...@gmail.com:
--
nosy: +Tim.Tisdall
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7834
___
___
Python-bugs-list
25 matches
Mail list logo
