[Python-Dev] Re: Should set objects maintain insertion order too?

[pylang]

A set was requested with preserved insertion order.  Mathematically, such a
structure relates more to an Oset (having order) than a Set.  See
relationships in the image below:

[image: libo.png]

Each of the mentioned structure types has a dedicated role.  Python's sets
work well and correlate with existing math principles.  I would be more
convinced to introduce a new collection to Python rather than alter
existing sets.

-1: preserving insertion-order in sets
 0: adding `OrderedSet` (where `dict.fromkeys()` does not suffice, i.e.
needing set operations)
+1: implementing an analogous abstract collection, e.g. "`HashList`" ->
Oset, just as `Counter` -> Mset

On Sun, Dec 29, 2019 at 9:00 PM Wes Turner  wrote:

> Due to version and platform constraints, a SAT solver is necessary for
> conda and (now) pip. Libsolv is one of the fastest around.
>
>  https://github.com/QuantStack/mamba is conda implemented with libsolv
> (and parallel downloading of *declarative* dependency metadata).
>
> For general purpose graphs with implicit node instantation from edge
> declaration, NetworkX has implementations of many graph algorithms.
>
> https://networkx.github.io/documentation/stable/reference/algorithms/generated/networkx.algorithms.dag.topological_sort.html
>
>
> CuGraph (a product of the RAPIDS.ai project) does graphs with CUDA (from
> Python) with a "NetworkX-like API" but doesn't yet have a topological sort
> (though it does have BFS)
> https://github.com/rapidsai/cugraph
>
> "pip needs a dependency resolver" + End (Fn+Right) links to the latest
> work on the new pip code (that must require declarative dependency metadata)
> https://github.com/pypa/pip/issues/988
>
> That said, this implementation of topo sort could have a deterministic
> output given an OrderedSet:
> https://rosettacode.org/wiki/Topological_sort#Python
>
> A table including Big-O and memory usage for the necessary data structure
> and methods would be useful.
>
> On Sun, Dec 29, 2019, 5:12 PM Tim Peters  wrote:
>
>> [Larry]
>> > It's a lightweight abstract dependency graph.  Its nodes are opaque,
>> > only required to be hashable.  And it doesn't require that you give it
>> > all the nodes in strict dependency order.
>> >
>> > When you add a node, you can also optionally specify
>> > dependencies, and those dependencies aren't required
>> > to be nodes that the graph has previously seen.  So you can add
>> > a node A that depends on B and C, without showing it B or C
>> > first.  When that happens it creates placeholder nodes for B
>> > and C, and naturally these nodes have no dependencies.  You
>> > can then later inform the graph that node B has dependencies
>> > on X Y and Z.
>> >
>> > (My specific use case is a package manager.  Packages are identified
>> > with unique strings.  So the nodes I give the give the graph are simply
>> > those package names.  It's pretty common for me to get a package
>> > with dependencies on packages I haven't seen yet.  Designing the
>> > graph to create placeholders let me skip making two passes over
>> > the package list, pre-creating the package objects, etc etc.  This
>> > made the code simpler and presumably faster.)
>> >
>> > The graph API maintains an externally-visible "ready" iterable of
>> > nodes.  And since B can go from ready to not-ready, it can get added
>> > to "ready" and subsequently removed.
>> >
>> > Also, when a node is satisfied, you simply remove it from the graph.
>> >  If A depends on B and C, and they all represent jobs, and B and C
>> > have no dependencies, they'll be in the "ready" iterable.  You iterate
>> > over "ready", and execute those jobs, and assuming they are
>> > successful you then remove them from the graph.  When A's
>> > dependencies are all satisfied, it'll get added to the "ready" iterable.
>> >  And naturally when B and C were removed from the graph, they were
>> > removed from the "ready" iterable too.
>>
>> OK!  You're doing a topological sort.  There are natural & simple ways
>> to do that right now that scale efficiently to very large graphs (time
>> & space linear in the sum of the number of nodes and the number of
>> dependencies).  Curiously, the difficulties are mostly driven by the
>> quality of _error_ messages you want (in case of, e.g., cycles in the
>> dependency graph).
>>
>> Lots of those implementations became deterministic "by magic" when
>> ordered dicts were introduced.  This is why:  a bare bones
>> implementation needs to associate two pieces of info with each node:
>> a list of its immediate successors, and an integer count of the number
>> of its immediate predecessors.  A dict is the natural way to implement
>> that association.
>>
>> When all the dependency info has been entered, then:
>>
>> - First all nodes are emitted whose predecessor count is 0.  Iterating
>> over the association dict once is the natural way to find them, and
>> that order is defined now.
>>
>> - Then, as each emitted node N is marked done:
>>   for child in N.succe

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[pylang]

Great timing! Last week I was trying to emulate a certain Rust example in
Python.
Rust has a way to implement families of classes without subclassing,
which I think could be a great addition to Python someday.  I'll explain
below.

Here is a Rust example (https://youtu.be/WDkv2cKOxx0?t=3795)
that demonstrates a way to implement classes without subclassing.

# Rust Code
enum Shape {
Circle(f32),
Square(f32),
Rectangle(f32, f32)
}

impl Shape {
fn area(self) -> f32 {
match self {
Shape::Circle(r) => 3.1 * r * r,
Shape::Square(l) => l * l,
Shape::Rectangle(l, w) => l * w
}
}
}

fn main () {
let c = Shape::Circle(3.0);
let s = Shape::Square(3.0);
let r = Shape::Rectangle(3.0, 7.5);
println!("○ {}", c.area());
println!("□ {}", s.area());
println!("▭ {}", r.area());
}

# Output
○ 27.88
□ 9
▭ 22.5

The general idea is:
- declare classes that share a certain type
- extend common methods with a match-case style

That's it.  No sub-classing required.

I wondered if someday, can we do this in Python? This match-case proposal
seems to fit well in this example.

While I know this PEP does not focus on detailed applications,
does anyone believe we can achieve elegant class creation (sans
subclassing) with match-cases?


On Wed, Jun 24, 2020 at 2:04 PM Guido van Rossum  wrote:

> On Tue, Jun 23, 2020 at 11:27 PM Emily Bowman 
> wrote:
> > I wonder if it's time to officially designate _ as a reserved name.
>
> Alas, it's too late for that. The i18n community uses _("message text") to
> mark translatable text. You may want to look into the gettext stdlib module.
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/P6EKIKFP6MX2N2KVFFCF4XUVVMSJ6Q5B/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZUBYRUF4G5CWYQGX5Z3C57K2ZWEHRDWJ/
Code of Conduct: http://python.org/psf/codeofconduct/