Make account_data accessible by madduck · Pull Request #295 · matrix-org/matrix-python-sdk

madduck · 2019-01-09T15:24:33Z

This keeps a copy of account_data in the Client object after a sync,
which can then be easily accessed through a dictionary.

In addition, Client.get_account_data is provided as a means to obtain
the current account_data structure for direct feeding into
Api.set_account_data.

Closes: #294
Signed-off-by: martin f. krafft madduck@madduck.net

This keeps a copy of account_data in the Client object after a sync, which can then be easily accessed through a dictionary. In addition, Client.get_account_data is provided as a means to obtain the current account_data structure for direct feeding into Api.set_account_data. Closes: Github matrix-org#294 Signed-off-by: martin f. krafft <madduck@madduck.net>

Zil0

Thanks for this! Please try to address the comments, as well as the PEP8 errors reported by Travis.

Note also that you're letting out per room account_data, which would be great to have if you get the time to look into it.

Zil0 · 2019-01-12T15:00:31Z

+client = MatrixClient(host)
+
+try:
+ client.login_with_password_no_sync(username, password)


This method is deprecated, simply use client.login with sync=False.

Zil0 · 2019-01-12T15:11:25Z

+room_ids = []
+
+import yaml
+print(yaml.dumps(client.account_data['m.direct']), default_flow_style=False)


Did you mean to use yaml.dump? Also you didn't sync so this will always raise KeyError.

Zil0 · 2019-01-12T15:14:42Z

@@ -0,0 +1,40 @@
+#!/usr/bin/env python3


I think you should drop this sample, as adding a 40 lines file with one line worth of information is not useful.
The comments below are FYI :)

Zil0 · 2019-01-12T15:30:26Z

 except MatrixRequestError:
 return False
+
+ def get_account_data(self):


Could you explain more precisely how this particular formatting is useful? Maybe give an example, as I don't get in what way it eases a call to api.set_account_data.

Hey, sorry for the late response, @Zil0. I chose to have another look.
I chose this particular formatting because it matches the JSON that the API returns. But looking at the api.set_account_data call, you're right, I can probably just return the account_data dict, do yo agree?

Zil0 · 2019-01-12T15:32:33Z

+def test_get_account_data():
+ client = MatrixClient("http://example.com")
+ assert isinstance(client.account_data, dict)
+ assert (len(client.account_data) == 0)


Outside parentheses look unnecessary, applies also to the lines below.

Zil0 · 2019-01-12T15:56:49Z

+ for event in response['account_data']['events']:
+ self.account_data[event['type']] = event['content']
+
+ for listener in self.listeners:


I think there's a problem with the way this is done.
A silly example is that if I want to listen for messages, I will add a listener with the event type m.room.message. But nothing stops me (at least not the HS) from having an event type in account_data which is also m.room.message. Then the listener will pick up both, which is not the expected behavior and could cause strange bugs. This may actually happen if you substitute m.room.message for an event type that is less well known.
Hence you should probably handle this with separate listeners, in the same way invite and presence listeners are done. Not 100% sure this is the right way though, so if you have another idea I'd gladly consider it!

Evidlo · 2019-02-16T03:26:09Z

@madduck Any idea when this might get finished?

madduck · 2019-02-18T00:09:05Z

Yeah, uh, sorry @Zil0 and @Evidlo, I had not seen these comments until now. The project I was working on is finished. At the moment, I have no other business with this SDK, and no spare time. So unless someone steps up to finish this, it'll be a while until I can return, probably until e2e is supported, then there'll be a new project lined up for me.

I am fine dropping the example. I find such files useful, but I see the point. The other stuff should be trivial fixes, right?

madduck · 2019-01-09T15:24:33Z

This keeps a copy of account_data in the Client object after a sync,
which can then be easily accessed through a dictionary.

In addition, Client.get_account_data is provided as a means to obtain
the current account_data structure for direct feeding into
Api.set_account_data.

Closes: #294
Signed-off-by: martin f. krafft madduck@madduck.net

This keeps a copy of account_data in the Client object after a sync, which can then be easily accessed through a dictionary. In addition, Client.get_account_data is provided as a means to obtain the current account_data structure for direct feeding into Api.set_account_data. Closes: Github matrix-org#294 Signed-off-by: martin f. krafft <madduck@madduck.net>

Zil0

Thanks for this! Please try to address the comments, as well as the PEP8 errors reported by Travis.

Note also that you're letting out per room account_data, which would be great to have if you get the time to look into it.

Zil0 · 2019-01-12T15:00:31Z

+client = MatrixClient(host)
+
+try:
+ client.login_with_password_no_sync(username, password)


This method is deprecated, simply use client.login with sync=False.

Zil0 · 2019-01-12T15:11:25Z

+room_ids = []
+
+import yaml
+print(yaml.dumps(client.account_data['m.direct']), default_flow_style=False)


Did you mean to use yaml.dump? Also you didn't sync so this will always raise KeyError.

Zil0 · 2019-01-12T15:14:42Z

@@ -0,0 +1,40 @@
+#!/usr/bin/env python3


I think you should drop this sample, as adding a 40 lines file with one line worth of information is not useful.
The comments below are FYI :)

Zil0 · 2019-01-12T15:30:26Z

 except MatrixRequestError:
 return False
+
+ def get_account_data(self):


Could you explain more precisely how this particular formatting is useful? Maybe give an example, as I don't get in what way it eases a call to api.set_account_data.

Hey, sorry for the late response, @Zil0. I chose to have another look.
I chose this particular formatting because it matches the JSON that the API returns. But looking at the api.set_account_data call, you're right, I can probably just return the account_data dict, do yo agree?

Zil0 · 2019-01-12T15:32:33Z

+def test_get_account_data():
+ client = MatrixClient("http://example.com")
+ assert isinstance(client.account_data, dict)
+ assert (len(client.account_data) == 0)


Outside parentheses look unnecessary, applies also to the lines below.

Zil0 · 2019-01-12T15:56:49Z

+ for event in response['account_data']['events']:
+ self.account_data[event['type']] = event['content']
+
+ for listener in self.listeners:


I think there's a problem with the way this is done.
A silly example is that if I want to listen for messages, I will add a listener with the event type m.room.message. But nothing stops me (at least not the HS) from having an event type in account_data which is also m.room.message. Then the listener will pick up both, which is not the expected behavior and could cause strange bugs. This may actually happen if you substitute m.room.message for an event type that is less well known.
Hence you should probably handle this with separate listeners, in the same way invite and presence listeners are done. Not 100% sure this is the right way though, so if you have another idea I'd gladly consider it!

Evidlo · 2019-02-16T03:26:09Z

@madduck Any idea when this might get finished?

madduck · 2019-02-18T00:09:05Z

Yeah, uh, sorry @Zil0 and @Evidlo, I had not seen these comments until now. The project I was working on is finished. At the moment, I have no other business with this SDK, and no spare time. So unless someone steps up to finish this, it'll be a while until I can return, probably until e2e is supported, then there'll be a new project lined up for me.

I am fine dropping the example. I find such files useful, but I see the point. The other stuff should be trivial fixes, right?

madduck · 2019-01-09T15:24:33Z

This keeps a copy of account_data in the Client object after a sync,
which can then be easily accessed through a dictionary.

In addition, Client.get_account_data is provided as a means to obtain
the current account_data structure for direct feeding into
Api.set_account_data.

Closes: #294
Signed-off-by: martin f. krafft madduck@madduck.net

This keeps a copy of account_data in the Client object after a sync, which can then be easily accessed through a dictionary. In addition, Client.get_account_data is provided as a means to obtain the current account_data structure for direct feeding into Api.set_account_data. Closes: Github matrix-org#294 Signed-off-by: martin f. krafft <madduck@madduck.net>

Zil0

Thanks for this! Please try to address the comments, as well as the PEP8 errors reported by Travis.

Note also that you're letting out per room account_data, which would be great to have if you get the time to look into it.

Zil0 · 2019-01-12T15:00:31Z

+client = MatrixClient(host)
+
+try:
+ client.login_with_password_no_sync(username, password)


This method is deprecated, simply use client.login with sync=False.

Zil0 · 2019-01-12T15:11:25Z

+room_ids = []
+
+import yaml
+print(yaml.dumps(client.account_data['m.direct']), default_flow_style=False)


Did you mean to use yaml.dump? Also you didn't sync so this will always raise KeyError.

Zil0 · 2019-01-12T15:14:42Z

@@ -0,0 +1,40 @@
+#!/usr/bin/env python3


I think you should drop this sample, as adding a 40 lines file with one line worth of information is not useful.
The comments below are FYI :)

Zil0 · 2019-01-12T15:30:26Z

 except MatrixRequestError:
 return False
+
+ def get_account_data(self):


Could you explain more precisely how this particular formatting is useful? Maybe give an example, as I don't get in what way it eases a call to api.set_account_data.

Hey, sorry for the late response, @Zil0. I chose to have another look.
I chose this particular formatting because it matches the JSON that the API returns. But looking at the api.set_account_data call, you're right, I can probably just return the account_data dict, do yo agree?

Zil0 · 2019-01-12T15:32:33Z

+def test_get_account_data():
+ client = MatrixClient("http://example.com")
+ assert isinstance(client.account_data, dict)
+ assert (len(client.account_data) == 0)


Outside parentheses look unnecessary, applies also to the lines below.

Zil0 · 2019-01-12T15:56:49Z

+ for event in response['account_data']['events']:
+ self.account_data[event['type']] = event['content']
+
+ for listener in self.listeners:


I think there's a problem with the way this is done.
A silly example is that if I want to listen for messages, I will add a listener with the event type m.room.message. But nothing stops me (at least not the HS) from having an event type in account_data which is also m.room.message. Then the listener will pick up both, which is not the expected behavior and could cause strange bugs. This may actually happen if you substitute m.room.message for an event type that is less well known.
Hence you should probably handle this with separate listeners, in the same way invite and presence listeners are done. Not 100% sure this is the right way though, so if you have another idea I'd gladly consider it!

Evidlo · 2019-02-16T03:26:09Z

@madduck Any idea when this might get finished?

madduck · 2019-02-18T00:09:05Z

Yeah, uh, sorry @Zil0 and @Evidlo, I had not seen these comments until now. The project I was working on is finished. At the moment, I have no other business with this SDK, and no spare time. So unless someone steps up to finish this, it'll be a while until I can return, probably until e2e is supported, then there'll be a new project lined up for me.

I am fine dropping the example. I find such files useful, but I see the point. The other stuff should be trivial fixes, right?

madduck · 2019-01-09T15:24:33Z

This keeps a copy of account_data in the Client object after a sync,
which can then be easily accessed through a dictionary.

In addition, Client.get_account_data is provided as a means to obtain
the current account_data structure for direct feeding into
Api.set_account_data.

Closes: #294
Signed-off-by: martin f. krafft madduck@madduck.net

This keeps a copy of account_data in the Client object after a sync, which can then be easily accessed through a dictionary. In addition, Client.get_account_data is provided as a means to obtain the current account_data structure for direct feeding into Api.set_account_data. Closes: Github matrix-org#294 Signed-off-by: martin f. krafft <madduck@madduck.net>

Zil0

Thanks for this! Please try to address the comments, as well as the PEP8 errors reported by Travis.

Note also that you're letting out per room account_data, which would be great to have if you get the time to look into it.

Zil0 · 2019-01-12T15:00:31Z

+client = MatrixClient(host)
+
+try:
+ client.login_with_password_no_sync(username, password)


This method is deprecated, simply use client.login with sync=False.

Zil0 · 2019-01-12T15:11:25Z

+room_ids = []
+
+import yaml
+print(yaml.dumps(client.account_data['m.direct']), default_flow_style=False)


Did you mean to use yaml.dump? Also you didn't sync so this will always raise KeyError.

Zil0 · 2019-01-12T15:14:42Z

@@ -0,0 +1,40 @@
+#!/usr/bin/env python3


I think you should drop this sample, as adding a 40 lines file with one line worth of information is not useful.
The comments below are FYI :)

Zil0 · 2019-01-12T15:30:26Z

 except MatrixRequestError:
 return False
+
+ def get_account_data(self):


Could you explain more precisely how this particular formatting is useful? Maybe give an example, as I don't get in what way it eases a call to api.set_account_data.

Hey, sorry for the late response, @Zil0. I chose to have another look.
I chose this particular formatting because it matches the JSON that the API returns. But looking at the api.set_account_data call, you're right, I can probably just return the account_data dict, do yo agree?

Zil0 · 2019-01-12T15:32:33Z

+def test_get_account_data():
+ client = MatrixClient("http://example.com")
+ assert isinstance(client.account_data, dict)
+ assert (len(client.account_data) == 0)


Outside parentheses look unnecessary, applies also to the lines below.

Zil0 · 2019-01-12T15:56:49Z

+ for event in response['account_data']['events']:
+ self.account_data[event['type']] = event['content']
+
+ for listener in self.listeners:


I think there's a problem with the way this is done.
A silly example is that if I want to listen for messages, I will add a listener with the event type m.room.message. But nothing stops me (at least not the HS) from having an event type in account_data which is also m.room.message. Then the listener will pick up both, which is not the expected behavior and could cause strange bugs. This may actually happen if you substitute m.room.message for an event type that is less well known.
Hence you should probably handle this with separate listeners, in the same way invite and presence listeners are done. Not 100% sure this is the right way though, so if you have another idea I'd gladly consider it!

Evidlo · 2019-02-16T03:26:09Z

@madduck Any idea when this might get finished?

madduck · 2019-02-18T00:09:05Z

Yeah, uh, sorry @Zil0 and @Evidlo, I had not seen these comments until now. The project I was working on is finished. At the moment, I have no other business with this SDK, and no spare time. So unless someone steps up to finish this, it'll be a while until I can return, probably until e2e is supported, then there'll be a new project lined up for me.

I am fine dropping the example. I find such files useful, but I see the point. The other stuff should be trivial fixes, right?

madduck · 2019-01-09T15:24:33Z

This keeps a copy of account_data in the Client object after a sync,
which can then be easily accessed through a dictionary.

In addition, Client.get_account_data is provided as a means to obtain
the current account_data structure for direct feeding into
Api.set_account_data.

Closes: #294
Signed-off-by: martin f. krafft madduck@madduck.net

This keeps a copy of account_data in the Client object after a sync, which can then be easily accessed through a dictionary. In addition, Client.get_account_data is provided as a means to obtain the current account_data structure for direct feeding into Api.set_account_data. Closes: Github matrix-org#294 Signed-off-by: martin f. krafft <madduck@madduck.net>

Zil0

Thanks for this! Please try to address the comments, as well as the PEP8 errors reported by Travis.

Note also that you're letting out per room account_data, which would be great to have if you get the time to look into it.

Zil0 · 2019-01-12T15:00:31Z

+client = MatrixClient(host)
+
+try:
+ client.login_with_password_no_sync(username, password)


This method is deprecated, simply use client.login with sync=False.

Zil0 · 2019-01-12T15:11:25Z

+room_ids = []
+
+import yaml
+print(yaml.dumps(client.account_data['m.direct']), default_flow_style=False)


Did you mean to use yaml.dump? Also you didn't sync so this will always raise KeyError.

Zil0 · 2019-01-12T15:14:42Z

@@ -0,0 +1,40 @@
+#!/usr/bin/env python3


I think you should drop this sample, as adding a 40 lines file with one line worth of information is not useful.
The comments below are FYI :)

Zil0 · 2019-01-12T15:30:26Z

 except MatrixRequestError:
 return False
+
+ def get_account_data(self):


Could you explain more precisely how this particular formatting is useful? Maybe give an example, as I don't get in what way it eases a call to api.set_account_data.

Hey, sorry for the late response, @Zil0. I chose to have another look.
I chose this particular formatting because it matches the JSON that the API returns. But looking at the api.set_account_data call, you're right, I can probably just return the account_data dict, do yo agree?

Zil0 · 2019-01-12T15:32:33Z

+def test_get_account_data():
+ client = MatrixClient("http://example.com")
+ assert isinstance(client.account_data, dict)
+ assert (len(client.account_data) == 0)


Outside parentheses look unnecessary, applies also to the lines below.

Zil0 · 2019-01-12T15:56:49Z

+ for event in response['account_data']['events']:
+ self.account_data[event['type']] = event['content']
+
+ for listener in self.listeners:


I think there's a problem with the way this is done.
A silly example is that if I want to listen for messages, I will add a listener with the event type m.room.message. But nothing stops me (at least not the HS) from having an event type in account_data which is also m.room.message. Then the listener will pick up both, which is not the expected behavior and could cause strange bugs. This may actually happen if you substitute m.room.message for an event type that is less well known.
Hence you should probably handle this with separate listeners, in the same way invite and presence listeners are done. Not 100% sure this is the right way though, so if you have another idea I'd gladly consider it!

Evidlo · 2019-02-16T03:26:09Z

@madduck Any idea when this might get finished?

madduck · 2019-02-18T00:09:05Z

Yeah, uh, sorry @Zil0 and @Evidlo, I had not seen these comments until now. The project I was working on is finished. At the moment, I have no other business with this SDK, and no spare time. So unless someone steps up to finish this, it'll be a while until I can return, probably until e2e is supported, then there'll be a new project lined up for me.

I am fine dropping the example. I find such files useful, but I see the point. The other stuff should be trivial fixes, right?

madduck · 2019-01-09T15:24:33Z

This keeps a copy of account_data in the Client object after a sync,
which can then be easily accessed through a dictionary.

In addition, Client.get_account_data is provided as a means to obtain
the current account_data structure for direct feeding into
Api.set_account_data.

Closes: #294
Signed-off-by: martin f. krafft madduck@madduck.net

This keeps a copy of account_data in the Client object after a sync, which can then be easily accessed through a dictionary. In addition, Client.get_account_data is provided as a means to obtain the current account_data structure for direct feeding into Api.set_account_data. Closes: Github matrix-org#294 Signed-off-by: martin f. krafft <madduck@madduck.net>

Zil0

Thanks for this! Please try to address the comments, as well as the PEP8 errors reported by Travis.

Note also that you're letting out per room account_data, which would be great to have if you get the time to look into it.

Zil0 · 2019-01-12T15:00:31Z

+client = MatrixClient(host)
+
+try:
+ client.login_with_password_no_sync(username, password)


This method is deprecated, simply use client.login with sync=False.

Zil0 · 2019-01-12T15:11:25Z

+room_ids = []
+
+import yaml
+print(yaml.dumps(client.account_data['m.direct']), default_flow_style=False)


Did you mean to use yaml.dump? Also you didn't sync so this will always raise KeyError.

Zil0 · 2019-01-12T15:14:42Z

@@ -0,0 +1,40 @@
+#!/usr/bin/env python3


I think you should drop this sample, as adding a 40 lines file with one line worth of information is not useful.
The comments below are FYI :)

Zil0 · 2019-01-12T15:30:26Z

 except MatrixRequestError:
 return False
+
+ def get_account_data(self):


Could you explain more precisely how this particular formatting is useful? Maybe give an example, as I don't get in what way it eases a call to api.set_account_data.

Hey, sorry for the late response, @Zil0. I chose to have another look.
I chose this particular formatting because it matches the JSON that the API returns. But looking at the api.set_account_data call, you're right, I can probably just return the account_data dict, do yo agree?

Zil0 · 2019-01-12T15:32:33Z

+def test_get_account_data():
+ client = MatrixClient("http://example.com")
+ assert isinstance(client.account_data, dict)
+ assert (len(client.account_data) == 0)


Outside parentheses look unnecessary, applies also to the lines below.

Zil0 · 2019-01-12T15:56:49Z

+ for event in response['account_data']['events']:
+ self.account_data[event['type']] = event['content']
+
+ for listener in self.listeners:


I think there's a problem with the way this is done.
A silly example is that if I want to listen for messages, I will add a listener with the event type m.room.message. But nothing stops me (at least not the HS) from having an event type in account_data which is also m.room.message. Then the listener will pick up both, which is not the expected behavior and could cause strange bugs. This may actually happen if you substitute m.room.message for an event type that is less well known.
Hence you should probably handle this with separate listeners, in the same way invite and presence listeners are done. Not 100% sure this is the right way though, so if you have another idea I'd gladly consider it!

Evidlo · 2019-02-16T03:26:09Z

@madduck Any idea when this might get finished?

madduck · 2019-02-18T00:09:05Z

Yeah, uh, sorry @Zil0 and @Evidlo, I had not seen these comments until now. The project I was working on is finished. At the moment, I have no other business with this SDK, and no spare time. So unless someone steps up to finish this, it'll be a while until I can return, probably until e2e is supported, then there'll be a new project lined up for me.

I am fine dropping the example. I find such files useful, but I see the point. The other stuff should be trivial fixes, right?

madduck · 2019-01-09T15:24:33Z

This keeps a copy of account_data in the Client object after a sync,
which can then be easily accessed through a dictionary.

In addition, Client.get_account_data is provided as a means to obtain
the current account_data structure for direct feeding into
Api.set_account_data.

Closes: #294
Signed-off-by: martin f. krafft madduck@madduck.net

This keeps a copy of account_data in the Client object after a sync, which can then be easily accessed through a dictionary. In addition, Client.get_account_data is provided as a means to obtain the current account_data structure for direct feeding into Api.set_account_data. Closes: Github matrix-org#294 Signed-off-by: martin f. krafft <madduck@madduck.net>

Zil0

Thanks for this! Please try to address the comments, as well as the PEP8 errors reported by Travis.

Note also that you're letting out per room account_data, which would be great to have if you get the time to look into it.

Zil0 · 2019-01-12T15:00:31Z

+client = MatrixClient(host)
+
+try:
+ client.login_with_password_no_sync(username, password)


This method is deprecated, simply use client.login with sync=False.

Zil0 · 2019-01-12T15:11:25Z

+room_ids = []
+
+import yaml
+print(yaml.dumps(client.account_data['m.direct']), default_flow_style=False)


Did you mean to use yaml.dump? Also you didn't sync so this will always raise KeyError.

Zil0 · 2019-01-12T15:14:42Z

@@ -0,0 +1,40 @@
+#!/usr/bin/env python3


I think you should drop this sample, as adding a 40 lines file with one line worth of information is not useful.
The comments below are FYI :)

Zil0 · 2019-01-12T15:30:26Z

 except MatrixRequestError:
 return False
+
+ def get_account_data(self):


Could you explain more precisely how this particular formatting is useful? Maybe give an example, as I don't get in what way it eases a call to api.set_account_data.

Hey, sorry for the late response, @Zil0. I chose to have another look.
I chose this particular formatting because it matches the JSON that the API returns. But looking at the api.set_account_data call, you're right, I can probably just return the account_data dict, do yo agree?

Zil0 · 2019-01-12T15:32:33Z

+def test_get_account_data():
+ client = MatrixClient("http://example.com")
+ assert isinstance(client.account_data, dict)
+ assert (len(client.account_data) == 0)


Outside parentheses look unnecessary, applies also to the lines below.

Zil0 · 2019-01-12T15:56:49Z

+ for event in response['account_data']['events']:
+ self.account_data[event['type']] = event['content']
+
+ for listener in self.listeners:


I think there's a problem with the way this is done.
A silly example is that if I want to listen for messages, I will add a listener with the event type m.room.message. But nothing stops me (at least not the HS) from having an event type in account_data which is also m.room.message. Then the listener will pick up both, which is not the expected behavior and could cause strange bugs. This may actually happen if you substitute m.room.message for an event type that is less well known.
Hence you should probably handle this with separate listeners, in the same way invite and presence listeners are done. Not 100% sure this is the right way though, so if you have another idea I'd gladly consider it!

Evidlo · 2019-02-16T03:26:09Z

@madduck Any idea when this might get finished?

madduck · 2019-02-18T00:09:05Z

Yeah, uh, sorry @Zil0 and @Evidlo, I had not seen these comments until now. The project I was working on is finished. At the moment, I have no other business with this SDK, and no spare time. So unless someone steps up to finish this, it'll be a while until I can return, probably until e2e is supported, then there'll be a new project lined up for me.

I am fine dropping the example. I find such files useful, but I see the point. The other stuff should be trivial fixes, right?

madduck · 2019-01-09T15:24:33Z

This keeps a copy of account_data in the Client object after a sync,
which can then be easily accessed through a dictionary.

In addition, Client.get_account_data is provided as a means to obtain
the current account_data structure for direct feeding into
Api.set_account_data.

Closes: #294
Signed-off-by: martin f. krafft madduck@madduck.net

This keeps a copy of account_data in the Client object after a sync, which can then be easily accessed through a dictionary. In addition, Client.get_account_data is provided as a means to obtain the current account_data structure for direct feeding into Api.set_account_data. Closes: Github matrix-org#294 Signed-off-by: martin f. krafft <madduck@madduck.net>

Zil0

Thanks for this! Please try to address the comments, as well as the PEP8 errors reported by Travis.

Note also that you're letting out per room account_data, which would be great to have if you get the time to look into it.

Zil0 · 2019-01-12T15:00:31Z

+client = MatrixClient(host)
+
+try:
+ client.login_with_password_no_sync(username, password)


This method is deprecated, simply use client.login with sync=False.

Zil0 · 2019-01-12T15:11:25Z

+room_ids = []
+
+import yaml
+print(yaml.dumps(client.account_data['m.direct']), default_flow_style=False)


Did you mean to use yaml.dump? Also you didn't sync so this will always raise KeyError.

Zil0 · 2019-01-12T15:14:42Z

@@ -0,0 +1,40 @@
+#!/usr/bin/env python3


I think you should drop this sample, as adding a 40 lines file with one line worth of information is not useful.
The comments below are FYI :)

Zil0 · 2019-01-12T15:30:26Z

 except MatrixRequestError:
 return False
+
+ def get_account_data(self):


Could you explain more precisely how this particular formatting is useful? Maybe give an example, as I don't get in what way it eases a call to api.set_account_data.

Hey, sorry for the late response, @Zil0. I chose to have another look.
I chose this particular formatting because it matches the JSON that the API returns. But looking at the api.set_account_data call, you're right, I can probably just return the account_data dict, do yo agree?

Zil0 · 2019-01-12T15:32:33Z

+def test_get_account_data():
+ client = MatrixClient("http://example.com")
+ assert isinstance(client.account_data, dict)
+ assert (len(client.account_data) == 0)


Outside parentheses look unnecessary, applies also to the lines below.

Zil0 · 2019-01-12T15:56:49Z

+ for event in response['account_data']['events']:
+ self.account_data[event['type']] = event['content']
+
+ for listener in self.listeners:


I think there's a problem with the way this is done.
A silly example is that if I want to listen for messages, I will add a listener with the event type m.room.message. But nothing stops me (at least not the HS) from having an event type in account_data which is also m.room.message. Then the listener will pick up both, which is not the expected behavior and could cause strange bugs. This may actually happen if you substitute m.room.message for an event type that is less well known.
Hence you should probably handle this with separate listeners, in the same way invite and presence listeners are done. Not 100% sure this is the right way though, so if you have another idea I'd gladly consider it!

Evidlo · 2019-02-16T03:26:09Z

@madduck Any idea when this might get finished?

madduck · 2019-02-18T00:09:05Z

Yeah, uh, sorry @Zil0 and @Evidlo, I had not seen these comments until now. The project I was working on is finished. At the moment, I have no other business with this SDK, and no spare time. So unless someone steps up to finish this, it'll be a while until I can return, probably until e2e is supported, then there'll be a new project lined up for me.

I am fine dropping the example. I find such files useful, but I see the point. The other stuff should be trivial fixes, right?

Zil0 suggested changes Jan 12, 2019
View reviewed changes

Zil0 added the Awaiting Changes label Jan 24, 2019

Zil0 suggested changes Jan 12, 2019
View reviewed changes

Zil0 added the Awaiting Changes label Jan 24, 2019

Zil0 suggested changes Jan 12, 2019
View reviewed changes

Zil0 added the Awaiting Changes label Jan 24, 2019

Zil0 suggested changes Jan 12, 2019
View reviewed changes

Zil0 added the Awaiting Changes label Jan 24, 2019

Zil0 suggested changes Jan 12, 2019
View reviewed changes

Zil0 added the Awaiting Changes label Jan 24, 2019

Zil0 suggested changes Jan 12, 2019
View reviewed changes

Zil0 added the Awaiting Changes label Jan 24, 2019

Zil0 suggested changes Jan 12, 2019
View reviewed changes

Zil0 added the Awaiting Changes label Jan 24, 2019

Zil0 suggested changes Jan 12, 2019
View reviewed changes

Zil0 added the Awaiting Changes label Jan 24, 2019

Uh oh!

Conversation

madduck commented Jan 9, 2019

Uh oh!

Zil0 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Evidlo commented Feb 16, 2019• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

madduck commented Feb 18, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

madduck commented Jan 9, 2019

Uh oh!

Zil0 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Evidlo commented Feb 16, 2019• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

madduck commented Feb 18, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

madduck commented Jan 9, 2019

Uh oh!

Zil0 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Evidlo commented Feb 16, 2019•
edited
Loading

Evidlo commented Feb 16, 2019•
edited
Loading

Evidlo commented Feb 16, 2019•
edited
Loading