Python version: 3.6
I am not super expert in Python, I was trying to use Tornado to implement a simple REST server and use non blocking coroutine to call a blocking function. When I return Json from the blocking function it fails with TypeError: 'dict' object is not callable
Here's the code
#gen.coroutine
def post(self):
jsonResponse = yield self.process_request(imageBytes)
self.write(json.dumps(jsonResponse))
#gen.coroutine
def process_request(self, imageBytes):
response = yield (executor.submit(self.test_func(), None))
return response
def test_func(self):
print('test func')
time.sleep(1)
jsonDataSet = {"text": "hello 123"}
return jsonDataSet
I am not sure what I am doing wrong, followed the sample code from Tornado reference. Any pointers will be helpful?
Latest:
I moved to async & await now I am getting "Object of type 'coroutine' is not JSON serializable"
async def test_func():
print('test func')
time.sleep(1)
jsonDataSet = {"text": "hello 123"}
return jsonDataSet
#return "test"
response = await `tornado.ioloop.IOLoop.current().run_in_executor(None, test_func)`
TypeError: 'dict' object is not callable
executor.submit() requires a callable, but you're already calling the test_func function. When you call test_func(), you're essentially passing its return value (which is a dict) to the submit() function.
You need pass this function without calling:
executor.submit(self.test_func, None)
Latest: I moved to async & await now I am getting "Object of type 'coroutine' is not JSON serializable"
run_in_executor is for running a normal function in a separate thread. It's not meant for running coroutines.
What's happening here is run_in_executor is calling test_func() coroutine, which automatically returns an awaitable object (because it's a coroutine).
If you want to execute test_func using run_in_executor, just make it a normal function (don't use async def).
Related
I am working through the hello world example and am getting an error when I compile with node. The issue is
let airdropSignature = await connection.requestAirdrop(
SyntaxError: await is only valid in async functions and the top level bodies of modules
It appears here that the connection.confirmTransaction is deprecated. In my VS code, I see a cross through the "confirmTransaction" portion of my code indicating an error there. How can I correct the code so that I avoid this error? Should the hello_world example in the documentation be updated to reflect this?
Your code is running into two problems:
the confirmTransaction method is not fully deprecated
your code is incorrectly using JavaScript async/await
1. confirmTransaction method is not fully deprecated
The #solana/web3.js method you (and the example code from the Solana docs) are using is not a fully deprecated method. But rather, the desired parameter format changed.
NOTE: You can see the source code of the confirmTransaction method here which may help you see the difference.
So in a sense, the confirmTransaction(string_of_tx_sig) format was deprecated. The new desired parameter format should pass an object as the first parameter, with the signature field defined. Like this:
await connection.confirmTransaction({ signature: airdropSignature });
Updating your code to using this updated parameter format will get rid of the "deprecated method line through". But either way, this should not cause your code to fail like it is.
2. Incorrect usage of async/await
The specific error message you are getting is due to the improper use of JavaScript's async/await functions.
Since you did not include much of your source code, I am guessing that you are attempting to call the await connection.requestAirdrop() function out side of an async function.
Perhaps just in the normal flow of a single JavaScript function like this:
const web3 = require("#solana/web3.js");
let airdropSignature = await connection.requestAirdrop(
payer.publicKey,
web3.LAMPORTS_PER_SOL
);
// using the deprecated parameter
await connection.confirmTransaction(airdropSignature);
Attempting to run this code above will result in the specific error message you gave since the requestAirdrop is not being run inside of a async function.
You can fix code in a few different ways, either:
creating a new "named" function with the async keyword before it, adding all the code above to within that function, then running that function. or,
creating an "arrow" fucntion that does effectively the same thing as the option above
For example:
Using a "named" function:
const web3 = require("#solana/web3.js");
async function main(){
let airdropSignature = await connection.requestAirdrop(
payer.publicKey,
web3.LAMPORTS_PER_SOL
);
// using the non-deprecated parameter
await connection.confirmTransaction({ signature: airdropSignature });
}
// now run the "named" function
main()
Using an "arrow" function:
const web3 = require("#solana/web3.js");
// create an run an inline "arrow" function
const runs_automatically = async () => {
let airdropSignature = await connection.requestAirdrop(
payer.publicKey,
web3.LAMPORTS_PER_SOL
);
// using the non-deprecated parameter
await connection.confirmTransaction({ signature: airdropSignature });
}
NOTE: We do not need to call our "arrow" function for it to execute the function's internal logic, unlike the "named" function
You can read more about arrow functions here on the Moz JavaScript docs.
In Python Lan Ref. 3.4.4, it is said that __aenter__() and __aexit__() must return awaitables. However, in the example async context manager, these two methods return None:
class AsyncContextManager:
async def __aenter__(self):
await log('entering context')
async def __aexit__(self, exc_type, exc, tb):
await log('exiting context')
Is this code correct?
__aenter__ and __aexit__ must return awaitables, but look what happens when you call the ones in the example:
>>> class AsyncContextManager:
... async def __aenter__(self):
... await log('entering context')
... async def __aexit__(self, exc_type, exc, tb):
... await log('exiting context')
...
>>> AsyncContextManager().__aenter__()
<coroutine object AsyncContextManager.__aenter__ at 0x7f5b092d5ac0>
It didn't return None! We got a coroutine object, which is awaitable.
These methods are async functions, which automatically return (awaitable) asynchronous coroutines. return statements in the body of an async function determine what gets returned when you await the coroutine, not what gets returned when you call the function.
This is similar to how generator functions return generator iterators, even though they usually have no return statement, and how if you write __iter__ as a generator function, you should not try to return an iterator inside the generator function.
So what happens if you do put a return in __aenter__ or __aexit__ defined as async functions? Well, you can, and if you do, the return statement doesn't have to return an awaitable. Here's what Python will do.
If you return something from an __aenter__ defined as an async function, that determines what gets bound to an as target, if the async with uses as.
If you return something from an __aexit__ defined as an async function, that determines whether to suppress exceptions that got raised inside the block. A "truthy" value tells the async with to suppress exceptions, while a "falsy" value tells the async with to let exceptions propagate. The default None is falsy, so by default, exceptions are not suppressed.
Here's an example:
import asyncio
class Example:
async def __aenter__(self):
return 3
async def __aexit__(self, exc_type, exc, tb):
return True
async def example():
async with Example() as three:
print(three == 3)
raise Exception
print("Exception got suppressed")
asyncio.run(example())
Output:
True
Exception got suppressed
Your __aenter__ method must return a context.
class MyAsyncContextManager:
async def __aenter__(self):
await log('entering context')
# maybe some setup (e.g. await self.setup())
return self
async def __aexit__(self, exc_type, exc, tb):
# maybe closing context (e.g. await self.close())
await log('exiting context')
async def do_something(self):
await log('doing something')
usage:
async with MyAsyncContextManager() as context:
await context.do_something()
I have a requirement that I need to create a service in Angular 1 and load data with an API call which can be accessed in controllers. I earlier tried by making a API call with $http service and assigning the data to the variable / object. I then injected the service and assigned the variable / object to the controller scope variable / object.
What I observed in the controller event loop is not same as service event loop and controller scope variable / object remains undefined. Later I got a solution to work by returning a promise from the service, and calling the promise in the controller, however I'm new to promises and not able to fully absorb that when I called a promise, I had to pass the function as argument which I think is a callback for the $http API call, but I'm uncertain how it's working under the hood. Can someone explain it?
//service code
this.getuserimages = function(uname) {
console.log("Username in UserImage Service: " + uname);
var promise = $http.get('/api/images/' + uname).then(function(response) {
this.userimages = response.data;
return this.userimages;
});
return promise;
}
// controller code
var userimagespromise = userImageService.getuserimages($routeParams.username);
userimagespromise.then(function(data) {
$scope.userimages = data;
Your code is a Promise chain.
I rewrited your code in a way that this chain is more clear, but the meaning is exactly the same:
$http.get('/api/images/' + uname)
.then(function(response) {
this.userimages = response.data;
return this.userimages;
})
.then(function(images) {
$scope.userimages = images;
});
You can read this flow in this way:
Please get me user images
And then, we they will be available (=> returned from the get and passed to the then function), save them in a variable and return them to the next element of the chain
And then, we they will be available (=> return from the previous promise), set them in the $scope
Please note that the entire flow is asynchronous because every Promise is "an object representing the eventual completion or failure of an asynchronous operation".
You can find more information in the Promise documentation.
The function fetch_details is called within the thread. It has a post request which raises the CustomError in case of failure. I need to test the
CustomError without actually making the actual post request.
Thread.new {
begin
details = fetch_details(a, b)
param1, param2 = parse_details(details, b)
post_result("Success", url)
rescue CustomError => e
post_result(e.message, url)
end
}
How do I stub the post request inside the fetch_details function to raise the Custom Error?
I have a routes class (sender), an actor and a helper class. From the routes class, I send a request to the actor and get a Future response. Now, I want to pass the future response to the helper and resolve it there.
TestRoute.scala:
val response: Future[Any] = (actor ? request) (timeout)
handler(response)(executionContext)
TestHelper.scala:
def handler(futureResponse: Future[Any])(implicit ec: ExecutionContext): StandardRoute = {
onComplete(futureResponse) {
case Success(s) => complete(s)
case Failure(f) => reject
}
}
The problem is that while onComplete works from within TestRoute.scala, it does not work when moved to TestHelper.scala. Any ideas what the problem might be?
EDIT: By "it does not work', I mean that the entire onComplete function is skipped over and not executed at all - no errors, just skips over.
There are few "oddities" with your code that may explain the issue.
1.I am surprised that your code even compiles given that futureResponse is of type Future[Any]. You should use mapTo to convert the Any to a known type T. The way you have the code constructed now implies that there is a Marshaller for Any which may be available in TestRoute but not in TestHelper.
2.The fact that response is a val and not a def means that the Actor will only be queried once, instead of once per request. I think you want something like:
type Output = ???
val response: () => Future[Output] =
() => (actor ? request) (timeout) andThen (_.mapTo[Output])
Which would change the signature of handler:
def handler(futureResponse: () => Future[Output])(implicit ec: ExecutionContext): StandardRoute =
onComplete(futureResponse()) {
case Success(s) => complete(s)
case Failure(f) => reject
}