Why not make the expressions available as attributes on the top level import?
See original GitHub issueThere might be a good reason for this I’m ignorant of, but wouldn’t it be nicer if you could do this:
import altair as alt
print(alt.datum) # <-- Just dummy code to illustrate accessing datum for use
Instead of this:
import altair as alt
from altair.expr import datum
print(datum)
Why not structure the expressions like datum
in a way that they are available to the alt
object without requiring a second import?
Issue Analytics
- State:
- Created 5 years ago
- Comments:12 (12 by maintainers)
Top Results From Across the Web
'Expressions are not allowed at the top level' if the module is ...
Apparently yes, as per this answer. However, there are no citations as to this behaviour. Update This is documented on the Swift blog:....
Read more >PEP 8 – Style Guide for Python Code
In particular: do not break backwards compatibility just to ... Surround top-level function and class definitions with two blank lines.
Read more >Specifying item attributes when using expressions
An attribute is said to be top level if it is not embedded within another attribute. For the ProductCatalog item, the top-level attributes...
Read more >Attributes — The Swift Programming Language (Swift 5.7)
If you don't use this attribute, supply a main.swift file with code at the top level that calls the NSApplicationMain(_:_:) function as follows:...
Read more >Python import: Advanced Techniques and Tips
You can also rename modules and attributes as they're imported: ... In particular, your top-level module and package names should be unique.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
In any case, I don’t think it makes sense to break conventions with the choices made in Vega-Lite, so I’m going to close this.
The reason it should not be symmetric with the
data
argument that you pass toChart
is that you’re not doing operations on the entire data set! You’re doing operations on one element at a time within one column of the data, for which “datum” seems a reasonable choice of nomenclature as any.