Alias for `Parameterized`?

[maximlt]

If I remember correctly I found Parameterized difficult to spell right originally (e after the t? z or s?). Parameterized is the most common usage apparently but that's not obvious to non native English speakers (or to me at least).

After typing it hundreds of time I've finally managed to remember the correct spelling, yet, these days I'm still regularly mistyping it, it's a pretty long name and I guess I don't type z that often which doesn't help. Auto-completion can help but there are a few Param- ish objects in param's namespace so you still have to choose between multiple options.

So I'm opening this issue to see whether I'm the only one who is having an issue with typing Parameterized? And if not, to see whether there would be some interest in trying to look for a simpler and shorter alias for Parameterized?

---

Just to bring some suggestions to the conversation, I thought about two candidates:

• param.ed (heavily inspired by attrs and its original and short attr.s and attr.ib API)
• param.Param

import param

class A(param.ed):
   s = param.String()

class A(param.Param):
    s = param.String()

[tomascsantos]

I like param.ed

[MarcSkovMadsen]

I constantly have issues remembering the correct spelling because Pytest uses parametrize.

[hoxbro]

I'm pretty sure I need to have param.ed in my life.

[MarcSkovMadsen]

Please conform to pep8

[maximlt]

Coming back to this almost a year later, I would still like to have a simplified version of Parameterized. I'm not sure which version is the best. I guess I could try experimenting with param.ed = param.Parameterized in my code and see how it feels.

Please conform to pep8

I'm not sure what you mean. If it's about ed vs Ed, I'm not sure which one is best (I have a slight preference for ed). The guide isn't too strict about this and there are already examples of non camel-case classes in Param with rx:

Class names should normally use the CapWords convention.

[MarcSkovMadsen]

[maximlt]

PEP8 is just a guide :)

---

How about Param? In the documentation or on forums I often have to mention Parameterized classes (where I don't always have autocompletion) while I think that saying a Param class would convey the same meaning. If param.Param feels a little too weird, I think I would also be fine with changing the way I import param, from:

import param

class P(param.Parameterized):
    s = param.String()

to

from param import Param, String

class P(Param):
    s = String()

It seems to me the latter approach would be more appropriate for users writing param code. This is for instance how SQLAlchemy code is documented:

from sqlalchemy import Table, Column, Integer, String, ForeignKey
from sqlalchemy.orm import registry

mapper_registry = registry()

user_table = Table(
    "user",
    mapper_registry.metadata,
    Column("id", Integer, primary_key=True),
    Column("name", String(50)),
    Column("fullname", String(50)),
    Column("nickname", String(12)),
)

class User:
    pass

mapper_registry.map_imperatively(User, user_table)

Perhaps @jbednar you could let us know if there's a particular reason param is using the param.<obj> style of coding?