I'm currently writing some async tests with pytest and found myself running into the following situation.
Consider we have an asyncio.Queue called peer2_subscriber that we want to check if it received a certain message (after triggering some action, omitted for brevity)
peer, cmd, msg = await asyncio.wait_for(
peer2_subscriber.get(),
timeout=1,
)
assert peer == peer2
assert isinstance(cmd, Transactions)
assert msg[0].hash == txs[0].hash
Now, consider that I want to test that another asyncio.Queue did NOT something pushed.
I found myself creating such a helper method.
async def wait_with_fallback(fn, fallback):
try:
return await asyncio.wait_for(
fn(),
timeout=1
)
except asyncio.TimeoutError:
return fallback
And then in the test I write something like:
val = await wait_with_fallback(
peer1_subscriber.get,
None
)
assert val == None
I wonder if there's an existing pattern that I'm missing?
Your pattern works, so I would say it's "correct", for certain values of correct… It's mostly stylistic views here. I would write either
await asyncio.sleep(1)
assert peer1_subscriber.empty()
or
await asyncio.sleep(1)
val = peer1_subscriber.get_nowait()
assert val is None
Related
I am trying to create a function in Groovy that inputs a string and returns a modified string. The problem I believe is within an addon, which is a specific software environment I am working with i.e. logic.script.Microblock. The error message I am receiving is:
No signature of method: com.controlj.addonsupport.logic.script.Microblock.capAbbreviate() is applicable for argument types: (java.lang.String) values: [OAT Dewpoint bavo].
I have tried dispName = capAbbreviate(dispName.toString()), dispName = capAbbreviate(dispName), and capAbbreviate(dispName).
The software environment is using some sort of addon. I am still fairly new to Groovy/Java so this seems like it could be something simple but it's not clicking in my head just yet.
The code simplified below is:
def exceptions = ['Ac':'AC','Oat':'OAT','Vav':'VAV']
def exceptionNonAlpha = '(?=[^a-zA-Z])'
def dispName
def capAbbreviate(String mbText)
{
// Iterates through 'exceptions' map and finds abbreviations and recapitalizes them
for (hvacName in exceptions.keySet()) {
mbText = mbText.replaceAll(hvacName + exceptionNonAlpha, exceptions[hvacName])
}
return mbText
}
logic.microblocks
{
dispName = prop.'display name'
dispName = capAbbreviate(dispName.toString()) // also tried capAbbreviate(dispName)
println dispName
}
The solution has two parts:
Similar to what #AndrejIstomin mentioned, removing the def to make a list or variable global resolved one part of the issue
The second part to the solution is that this. needed to be used to call the method. i.e. this.capAbbreviate(dispName)
I'm hoping to avoid any use of Celery at the moment. In Starlette's docs they give two ways to add background tasks:
Via Graphene: https://www.starlette.io/graphql/
class Query(graphene.ObjectType):
user_agent = graphene.String()
def resolve_user_agent(self, info):
"""
Return the User-Agent of the incoming request.
"""
user_agent = request.headers.get("User-Agent", "<unknown>")
background = info.context["background"]
background.add_task(log_user_agent, user_agent=user_agent)
return user_agent
Via a JSON response: https://www.starlette.io/background/
async def signup(request):
data = await request.json()
username = data['username']
email = data['email']
task = BackgroundTask(send_welcome_email, to_address=email)
message = {'status': 'Signup successful'}
return JSONResponse(message, background=task)
Does anyone know of a way to add tasks to Starlette's background with Ariadne? I am unable to return a JSONResponse in my resolver, and I do not have access to a info.context["background"]. The only thing I have attached to my context is my request object.
Solved!
Starlette Middleware:
class BackgroundTaskMiddleware(BaseHTTPMiddleware):
async def dispatch(
self, request: Request, call_next: RequestResponseEndpoint
) -> Response:
request.state.background = None
response = await call_next(request)
if request.state.background:
response.background = request.state.background
return response
Ariadne Resolver:
#query.field("getUser")
#check_authentication
async def resolve_get_user(user, obj, info):
task = BackgroundTasks()
task.add_task(test_func)
task.add_task(testing_func_two, "I work now")
request = info.context["request"]
request.state.background = task
return True
async def test_func():
await asyncio.sleep(10)
print("once!!")
async def testing_func_two(message: str):
print(message)
The functions still execute synchronously, but because they're background tasks I'm not too worried.
More discussion here.
The above which is marked as a solution does not work for me since BackgroundTask does not work properly when you use a middleware that subclasses BaseHTTPMiddleware see here:
https://github.com/encode/starlette/issues/919
In my case basically the task is not ran in the background and it is awaited to be completed, also I am not using Ariadne, but this should let you do the job and run a task in the background
Edit:
This worked for me.
executor = ProcessPoolExecutor()
main.executor.submit(
bg_process_funcs,
export_file_format,
export_headers,
data,
alert_type,
floor_subtitle,
date_subtitle,
pref_datetime,
pref_timezone,
export_file_name,
export_limit,)
executor.shutdown()
logger.info("Process Pool Shutdown")
I recently designed a REST API using flask for a sample project. The front end was based on React.JS. But i got a feedback from a colleague that the API is not REST API and its RPC.
The API basically accepts 3 parameters, 2 numbers and a operation ('add','sub','mul','div'). on an end point http://127.0.0.1:5000/calculator
The input JSON will look like:
{"value1":"7.1","value2":"8","operator":"mul"}
from flask import Flask, jsonify, request, abort
from flask_cors import CORS
APP = Flask(__name__, static_url_path='')
CORS(APP) # For cross origin resource sharing
APP.config['CORS_HEADERS'] = 'Content-Type'
#APP.route('/calculator', methods=['POST'])
def calculator_operation():
if not request.json:
abort(400)
try:
val1 = float(request.json['value1'])
val2 = float(request.json['value2'])
operator = request.json['operator']
if operator == 'add':
result = val1 + vla2
elif operator == 'mul':
result = val1 * val2
elif operator == 'sub':
result = val1 - val2
elif operator == 'div' and val2 == 0:
result = 'Cant divide by 0'
elif operator == 'div':
result = round((val1 / val2), 2)
return (jsonify({'result': result}), 200)
except KeyError:
abort(400)
if __name__ == '__main__':
APP.run(debug=True)
The code works fine. I would like to know if this is REST or RPC based on the end points and the operation being performed.
EDIT:
Ajax Call
$.ajax({
type: "POST",
url: "http://127.0.0.1:5000/calculator",
data: JSON.stringify({
value1: arg1,
value2: arg2,
operator: this.state.operation
}),
contentType: "application/json",
dataType: "json",
success:( data ) => {
this.setState({ result: data.result, argumentStr: data.result });
},
error: (err) => {
console.log(err);
}
});
I would like to know if this is REST or RPC based on the end points and the operation being performed.
How does the client discover what the endpoint is, and what the input json looks like?
On the web, there would be a standard media type that describes forms; the representation of the form would include keys and values, a target URI, and an HTTP method to use. The processing rules would describe how to take the details of the form, and the values provided by the consumer, and from them construct an HTTP request.
That's REST: doing what we do on the web.
Another REST approach would be to define a link relation, perhaps "http://example.org/calculator", and a media type application/prs.calculator+json, and then document that in your context the "http://example.org/calculator" link relation indicates that the target URI responds to POST messages with payload application/prs.calculator+json. This is essentially what Atom Syndication and Atom Pub.
That's also REST.
Fielding made an interesting comment about an API he had designed
I should also note that the above is not yet fully RESTful, at least how I use the term. All I have done is described the service interfaces, which is no more than any RPC. In order to make it RESTful, I would need to add hypertext to introduce and define the service, describe how to perform the mapping using forms and/or link templates, and provide code to combine the visualizations in useful ways.
That said, if you are performing GET-with-a-payload, a semantically safe request with a body, then you are probably trapped in RPC thinking. Notice that on the web, parameterized reads are done by communicating to the client how to modify the target-uri (for instance, by appending a query string with data encoded according to standardized processing rules).
REST stands for REpresentational State Transfer. Your operation is stateless, therefore there is no state to transfer. Your operation does, however, accept arguments and return a result in the manner of a procedure or function, and it is remote, so Remote Procedure Call would be a good description of what's going on. You are, after all, providing a language-independent way for clients to call your calculator_operation procedure.
What's conspicuously missing from your model is server-side data. In general, a REST API provides a way to interact with server-side objects: to query, create, replace, update, or delete. There's no data kept on your server side: it's just an oracle which answers questions. You have the "query" aspect and nothing else.
I've implement a redux effect takeLeading that will ignore subsequent actions if the saga is currently running:
export const takeLeading = (patternOrChannel, saga, ...args) => fork(function*() {
while (true) {
const action = yield take(patternOrChannel);
yield call(saga, ...args.concat(action));
}
});
I use this for API fetching in my application, where each endpoint in my API has its own action type. So for GET methods it's useful to block if the request has already been dispatched somewhere else in the app. The saga looks like:
return function* () {
yield all([takeLeading(GET_USER_ID, callApiGen), takeLeading(GET_WIDGET_ID, callApiGen)]);
}
The obvious problem is that if I want to get two different user IDs, the second will block because it too has action type GET_USER_ID. Short of making a different action for each possible parameter, is there a way to implement some takeLeadingForFunc(<action>, (action) => <id>, saga) that allows me to keep the concise format of specifying one effect per request type but allows me to not block if the <id> is different? I was trying to wrap takeLeading with takeEvery to implement something but couldn't quite get it.
EDIT:
I got something like this to work:
export const takeLeadingForFunc = (f) => (patternOrChannel, saga, ...args) => fork(function*() {
let takeLeadings = {};
while (true) {
const action = yield take(patternOrChannel);
if (!(f(action) in takeLeadings)) {
yield call(saga, ...args.concat(action))
takeLeadings[f(action)] = yield takeLeading((ac) => f(ac) === f(action) && ac.type === action.type, saga, ...args)
}
}
});
Which takes an extractor function f that should return a primitive. This feels kind of hacky, so was wondering if there's a more idiomatic way to do this.
I would like calls to /contacts/1.json to return json, 1.api to return browsableAPI, and calls with format=None aka /contacts/1/ to return a template where we call render_form. This way end-users can have pretty forms, and developers can use the .api format, and ajax/apps etc use .json. Seems like a common use case but something isn't clicking for me here in DRF...
Struggling with how DRF determines the Renderer used when no format is given. I found and then lost some info here on stack exchange that basically said to split the responses based on format. Adding the TemplateHTMLRenderer caused all sorts of pain. I had tried to split based on format but that is giving me JSON error below.
I don't understand the de facto way to define what renderer should be used. Especially when no format is provided. I mean, it "just works" when using Response(data). And I can get the TemplateHTMLRenderer to work but at the cost of having no default Renderer.
GET /contacts/1/ Gives the error:
<Contact: Contact object> is not JSON serializable
Using this code:
class ContactDetail(APIView):
permission_classes = (permissions.IsAuthenticatedOrReadOnly,
IsOwnerOrReadOnly,)
queryset = Contact.objects.all()
renderer_classes = (BrowsableAPIRenderer, JSONRenderer, TemplateHTMLRenderer,)
"""
Retrieve, update or delete a contact instance.
"""
def get_object(self, pk):
try:
return Contact.objects.get(pk=pk)
except Contact.DoesNotExist:
raise Http404
def get(self, request, pk, format=None):
contact = self.get_object(pk)
serializer = ContactSerializer(contact)
if format == 'json' or format == "api":
return Response(serializer.data)
else:
return Response({'contact': contact, 'serializer':serializer}, template_name="contact/contact_detail.html")
But GET /contacts/1.json , 1.api, or 1.html ALL give me the correct output. So it seems that I have created an issue with the content negotiation for the default i.e. format=None
I must be missing something fundamental. I have gone through the 2 tutorials and read the Renderers docs but I am unclear on what I messed up here as far as the default. I am NOT using the DEFAULT_RENDERERS in settings.py, didn't seem to make a difference if in default or inside the actual class as shown above.
Also if anyone knows a way to use TemplateHTMLRenderer without needing to switch on format value, I'm all ears.
EDIT: IF I use
if format == 'json' or format == "api" or format == None:
return Response(serializer.data)
else:
return Response({'contact': contact, 'serializer':serializer},
Then I am shown the browsable API by default. Unfortunately, what I want is the Template HTML view by default, which is set to show forms for end users. I would like to keep the .api format for developers.
TL; DR: Check the order of your renderers - they are tried in order of declaration until a content negotiation match or an error occurs.
Changing the line
renderer_classes = (BrowsableAPIRenderer, JSONRenderer, TemplateHTMLRenderer, )
to
renderer_classes = (TemplateHTMLRenderer, BrowsableAPIRenderer, JSONRenderer, )
Worked for me. I believe the reason is because the content negotiator starts at the first element in the renderer classes tuple when trying to find a renderer. When I have format==None, I'm thinking there is nothing else for DRF to go on, so it assumes I mean the "default" which seems to be the first in the tuple.
EDIT: So, as pointed out by #Ross in his answer, there is also a global setting in the settings.py for the project. If I remove my class level renderer_classes declaration and instead use this in settings.py
# ERROR
REST_FRAMEWORK = {
'DEFAULT_RENDERER_CLASSES': (
'rest_framework.renderers.BrowsableAPIRenderer',
'rest_framework.renderers.JSONRenderer',
'rest_framework.renderers.TemplateHTMLRenderer',
)
}
Then I get a (different) JSON error. However, as long as
'rest_framework.renderers.BrowsableAPIRenderer',
is not listed first, for example:
# SUCCESS, even though JSON renderer is checked first
'DEFAULT_RENDERER_CLASSES': (
'rest_framework.renderers.JSONRenderer',
'rest_framework.renderers.TemplateHTMLRenderer',
'rest_framework.renderers.BrowsableAPIRenderer',
)
So if we hit BrowsableAPIRenderer before we try TemplateHTMLRenderer then we get an error - whether or not we are relying on renderer_classes or DEFAULT_RENDERER_CLASSES. I imagine it passes through JSONRenderer gracefully but for whatever reason BrowsableAPIRenderer raises an exception.
So I have simplified my view code after analyzing this...
def get(self, request, pk, format=None):
contact = self.get_object(pk)
serializer = ContactSerializer(contact)
if format == None:
return Response({'contact': contact, 'serializer':serializer}, template_name="contact/contact_detail.html")
else:
return Response(serializer.data)
..which better reflects what I was originally trying to do anyway.
When I look at the source code, the priority seems to be the order of the renderers specified in the DEFAULT_RENDERER_CLASSES parameter in settings.py:
REST_FRAMEWORK = {
'DEFAULT_RENDERER_CLASSES': (
'rest_framework.renderers.JSONRenderer',
'rest_framework.renderers.TemplateHTMLRenderer',
),
'DEFAULT_PARSER_CLASSES': (
'rest_framework.parsers.JSONParser',
'rest_framework.parsers.TemplateHTMLRenderer',
)
}
So, if you specify a bunch of renderer classes, the first renderer that is valid will be selected based on if it is valid for the request given the .json/.api/.html extension and the Accept: header (not content-type, as I said in the comment on your question).