Context is a HashMap<String, Py<PyAny>>

[jonathan-s]

Since the variables are Py<PyAny>> they are treated as python variables at first, and only if they are further processed they get rust types.

It would be ideal to have the context considered to be each correct type directly so that when variables are resolved they are done without necessarily taking the python type route.

Looking into this >

django-rusty-templates/src/render/common.rs

Lines 17 to 60 in 1b8c71b

	impl Resolve for Variable {
	fn resolve<'t, 'py>(
	&self,
	py: Python<'py>,
	template: TemplateString<'t>,
	context: &mut Context,
	) -> ResolveResult<'t, 'py> {
	let mut parts = self.parts(template);
	let (first, mut object_at) = parts.next().expect("Variable names cannot be empty");
	let mut variable = match context.context.get(first) {
	Some(variable) => variable.bind(py).clone(),
	None => return Ok(None),
	};
	for (part, key_at) in parts {
	variable = match variable.get_item(part) {
	Ok(variable) => variable,
	Err(_) => match variable.getattr(part) {
	Ok(variable) => variable,
	Err(_) => {
	let int = match part.parse::<usize>() {
	Ok(int) => int,
	Err(_) => {
	return Err(RenderError::VariableDoesNotExist {
	key: part.to_string(),
	object: variable.str()?.to_string(),
	key_at: key_at.into(),
	object_at: Some(object_at.into()),
	}
	.into())
	}
	};
	match variable.get_item(int) {
	Ok(variable) => variable,
	Err(_) => todo!(),
	}
	}
	},
	};
	object_at.1 += key_at.1 + 1;
	}
	Ok(Some(Content::Py(variable)))
	}
	}

and the type that gets returned might solve this.

See this thread for more context.

Originally posted by @jonathan-s in #70 (comment)

As a side-effect of this current behaviour, the test cases in rust needs to be written rather awkwardly to cover other match arms.

[LilyFoote]

Yeah, I think we should definitely look into this at some point. I think I'd like to get more of the complicated {% tag %} implementations done first though.