New package: NumExpr v1.0.0

[JuliaRegistrator]

• Registering package: NumExpr
• Repository: https://github.com/bhftbootcamp/NumExpr.jl
• Created by: @DeevsDeevs
• Version: v1.0.0
• Commit: 6f570155fbd0d72c0b11ab7e602cbd67e358efea
• Reviewed by: @DeevsDeevs
• Reference: bhftbootcamp/NumExpr.jl@6f57015#commitcomment-139158660
• Description: The NumExpr library is designed to handle and evaluate arithmetic expressions. It enables parsing and analyzing expressions, as well as performing calculations with user-defined functions

[github-actions]

Your new package pull request met all of the guidelines for auto-merging and is scheduled to be merged when the mandatory waiting period (3 days) has elapsed.

Since you are registering a new package, please make sure that you have read the package naming guidelines: https://pkgdocs.julialang.org/v1/creating-packages/#Package-naming-guidelines

---

If you want to prevent this pull request from being auto-merged, simply leave a comment. If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment. You can edit blocking comments, adding [noblock] to them in order to unblock auto-merging.

[gdalle]

Hi, and congrats on the new package! In my opinion, the name is too short, and too close to the type name Expr. Longer package names are never a bad thing in Julia, so I encourage you to consider something like NumericalExpressions

[aplavin]

As another datapoint: from the name, I thought it's a Julia port of (quite popular) https://github.com/pydata/numexpr. Was interested and clicked.
But it isn't, right?
[noblock]

[DeevsDeevs]

@gdalle Thank you for your feedback on the proposed package name. I understand your concerns regarding its length and similarity to existing names. However, I’d like to offer some considerations in favor of retaining the chosen name, “NumExpr”:

1. Brevity and Functionality: A shorter name facilitates easier function overloading without the need for additional aliasing logic. This enhances usability and code readability, which are core tenets of Julia’s design philosophy.
2. Conventional Abbreviations: “Num” and “Expr” are widely recognized abbreviations for “Numerical” and “Expression,” respectively. This naming convention is intuitive for users familiar with mathematical and programming terminologies, ensuring the package’s purpose is immediately clear.
3. Distinctive Functionality: While our package shares a name resemblance with the Python ‘numexpr’, it is not a port nor directly inspired by it. Our work is poised to introduce a powerful backend for reactive mathematical computations, distinguishing itself in functionality and scope. The name “NumExpr” succinctly reflects our package’s focus on numerical expressions, aligning with its innovative approach.

Our intention is not to confuse but to maintain a clear and functional identity within the Julia ecosystem.
[noblock]

[goerz]

Brevity and Functionality

Brevity is not desirable in Julia packages, and it does not affect functionality. (Sometimes there are good short package names, but you really have to get off this “brevity” train)

This name in particular would be pretty much okay. But the existence of https://github.com/pydata/numexpr is a problem. So we have the exact same situation as with Serde now. This is what I meant with you having to do some research on your proposed package names.

The best thing to do is to avoid another long discussion and to rename to something like NumericalExpressions

[goerz]

@FrancescAlted As the maintainer of https://github.com/pydata/numexpr, would you like to weigh in here? In a situation like this, your “yes” or “no” would likely be the deciding factor for whether this Julia package will be accepted

[gryumov]

@goerz Does NumExpr violate any copyrights?

[goerz]

That's not the point. We don't go by legalities here. A Julia package NumExpr could be considered misrepresenting itself as being associated with the existing https://github.com/pydata/numexpr. And at the very least, it's polite to check with the existing project whether they see this as impinging on their "brand" (not in the sense of a trademark, just basic common sense).

[gryumov]

Hi, and congrats on the new package! In my opinion, the name is too short, and too close to the type name Expr. Longer package names are never a bad thing in Julia, so I encourage you to consider something like NumericalExpressions

Thanks for your comment on the package. The Julia community should not hinder individual preferences, as doing so could limit our self-expression and the creative freedom that's essential.

@gdalle cc

[goerz]

The Julia community should not hinder individual preferences, as doing so could limit our self-expression and the creative freedom that's essential.

The General registry is a shared community resource. If you cannot follow the guidelines, the best course of action might be to use a LocalRegistry for your organization.

[dmitrii-doronin]

The Julia community should not hinder individual preferences, as doing so could limit our self-expression and the creative freedom that's essential.

The General registry is a shared community resource. If you cannot follow the guidelines, the best course of action might be to use a LocalRegistry for your organization.

Speaking about guidelines, the name satisfies all the points in juliadocs. If there're more of them, then they all should be very explicit and in one place.

Also the other package naming guidelines in CONTRIBUTING.md is unfortunately broken.

[noblock]

[goerz]

NumExpr as a name doesn't specifically violate any guidelines. It would probably be fine if it wasn't for the existing https://github.com/pydata/numexpr

But part of the registration process is the community review. With the https://github.com/bhftbootcamp/ organization, you have a pattern of brushing up against the expectations of the community. In fact, not just the Julia community, but the larger open-source community, by reusing the names of existing projects without any relation to those projects. It feels like you just want to do your own thing. That's fine! But, I really think you would be better served by managing your own LocalRegistry

[LilithHafner]

I have proposed a new package naming guideline that will be relevant to this discussion if it receives community approval. (JuliaLang/julia#53514)

Also the other package naming guidelines in CONTRIBUTING.md is unfortunately broken.

Thank you for pointing that out. #101935

[FrancescAlted]

Hey, that's a bit late, but I personally don't have inconvenient in other projects using the same name. I agree in that perhaps, and provided how close Julia and Python ecosystems are, using the same name wouldn't be the wisest of the decisions, and can lead to some confusion. But again, this not posing a particular problem or inconvenience to me.

[goerz]

provided how close Julia and Python ecosystems are, using the same name wouldn't be the wisest of the decisions, and can lead to some confusion

Yeah, personally, I would lean towards keeping the NumExpr name open for a future Julia package that is directly related to the Python package. On the other hand, we usually have a first-come-first-serve policy. So, this is pretty much a maintainer decision at this point.

Of course, if @DeevsDeevs comes around to renaming to the recommended NumericalExpressions, or to use a LocalRegistry for their organization (so we don’t have this situation again for the next package registration), the point is moot.

[DeevsDeevs]

@goerz So if FrancesAlted has no problems with us using this package name, i believe we want to continue with it.
[noblock]

[LilithHafner]

I oppose this name for 3 reasons:

1. Package naming guideline 4 says

Err on the side of clarity, even if clarity seems long-winded to you.

RandomMatrices is a less ambiguous name than RndMat or RMT, even though the latter are shorter.

This applies directly to this case. NumericalExpressions is a better name than NumExpr for the General registry.

2. In Julia, the abbreviation Expr refers most commonly to Base.Expr. This package is for working with numerical expressions, rather than the Julia Expr type, so using the Expr abbreviation is confusing/possibly misleading.

3. Also relevant, though less of a blocker imo is the new guideline 8 on https://docs.julialang.org/en/v1.12-dev/tutorials/creating-packages/#Package-naming-guidelines (link should be valid after the next documentation deployment within a few hours)

Avoid using a distinctive name that is already in use in a well known, unrelated project.

I think that each of 1 and 2 alone would be sufficient to warrant renaming. 3 is more ambiguous.

[DeevsDeevs]

@LilithHafner @goerz Thank you again for your feedback, however i don't really agree with your proposal. Some key factors for that are:

1. Community Consensus: Getting FrancescAlted's nod was about ensuring community buy-in. If that's not a key factor, what is?
2. Guideline Timing: The new guidelines came in mid-discussion. They should apply to future packages, not retroactively affect ours. Changing rules midway shouldn't impact already submitted proposals.
3. Practical Naming: "Expr" in our name is practical and specific. With clear documentation, any confusion is minimal.

Let's aim for a balanced and fair approach, respecting the collaborative spirit and the timing of guideline updates.
[noblock]

[goerz]

Community Consensus: Getting FrancescAlted's nod was about ensuring community buy-in.

FrancescAlted definitely had an absolute veto on this name, which they didn't exercise. But the more relevant community is the Julia community, and there's no consensus there. Actually, there is: the consensus in the community is that you should rename the package, but you are refusing to do so.

So at this point, the question is whether there's a maintainer who feels "the author should have the last word" outweighs the interests of the community.

Guideline Timing: The new guidelines came in mid-discussion.

Being the cause of a new community guideline is about the strongest rebuke you could possibly get.

Let's aim for a balanced and fair approach,

You've not given an inch here, so I don't see how this is "balanced". Why are you so resistant to NumericalExpressions?

[LilithHafner]

Your points 1 & 2 address my point 3. Honestly, my point 3 is not particularly strong anyway.

With respect to the Concision/Clarity tradeoff, we try to situate ourselves on the side of clarity. Ideally, we want folks to get a reasonably accurate picture of what the package does from the name alone. Documentation is great and essential, but it's not a substitute for this.

Additionally, it is nice for folks to be able to easily guess/remember package names by always using the canonical (i.e full) representation of words. That way you just remember the concepts in the name and don't have to remember the abbreviations too.

[dmitrii-doronin]

Your points 1 & 2 address my point 3. Honestly, my point 3 is not particularly strong anyway.

With respect to the Concision/Clarity tradeoff, we try to situate ourselves on the side of clarity. Ideally, we want folks to get a reasonably accurate picture of what the package does from the name alone. Documentation is great and essential, but it's not a substitute for this.

Additionally, it is nice for folks to be able to easily guess/remember package names by always using the canonical (i.e full) representation of words. That way you just remember the concepts in the name and don't have to remember the abbreviations too.

It's not simply about concision and clarity. We are having this discussion in part because of the current naming guidelines. They are simply too rigid and they seem to not follow trends of the modern languages. I don't see people complaining about package names in Rust, Golang or even C++. And in case of the general registry it significantly undermines the goals of being a 'shared community space'.

Moreover, using full names hinders creativity and makes the namespace limited and ugly. What if somebody wants to register a package with similar functionality? Are they going to call it 'ExpressionsNumerical' or 'NumericalExpressions2'? Both of these names seem underwhelming to say the least.

Lastly, I'm yet to come to a moment where I forget a name of a package I'm actively developing with. IMO, it's easier to remember a good and catchy name than something so general it can be considered terminology.
[noblock]

[goerz]

[The current naming guidelines] are simply too rigid and they seem to not follow trends of the modern languages. I don't see people complaining about package names in Rust, Golang or even C++. And in case of the general registry it significantly undermines the goals of being a 'shared community space'.

That's the whole point we're trying to get across! The package naming conventions are deliberately different from the conventions in these other languages. Different languages have different conventions, and you should follow the conventions of the language you are using. NumericalExpressions would not be a good name for a Python or C++ package, but it would, for a Julia package.

Moreover, using full names hinders creativity and makes the namespace limited and ugly.

It is the strong consensus of the Julia community that we want packages to be named that way (with some specific exceptions). We still very much allow for creative names; not every package name has to be of the explicit form of NumericalExpressions. But NumExpr is in no way an example of a creative package name. It is simply a short name, which does not match the guidelines.

Your ideas on package naming are just not compatible with the General registry, which is why every package registration coming out of your organization has been problematic. If you are unwilling to adapt, please create a LocalRegistry for your organization that meets your expectations.

[LilithHafner]

We are having this discussion in part because of the current naming guidelines. They are simply too rigid and they seem to not follow trends of the modern languages.

If you would like to change the current naming guidelines, feel free to make a proposal and solicit community support (e.g. JuliaLang/julia#53514)

[goerz]

I would also point out that when package names deviate from the normal conventions, that in itself has connotations that can be quite informative. For example, I would expect an NumExpr to be "close to core" (due to the connection to the Base.Expr), or, even more likely, to have some relation to an existing non-Julia project (like the Python-numexpr). Wrapping or re-implementing an existing library is the most common reason to choose a "non-Julian" name (and is quite routine). In fact, a Julia translation of the Python-numexpr should use the name NumExpr.

For this package, it has none of the connotations that would justify deviating from the conventions.

[gryumov]

Оkay, If the main problem is using a reserved name in Python, what do you think about the name VarExpr?
@DeevsDeevs @goerz cc

[goerz]

USE A LONG DESCRIPTIVE NAME. How many times do we have to explain this?

You are clearly not getting the point, so please do not register your packages in General. You should use a LocalRegistry.

the main problem is using a reserved name in Python

No, the main problem is that you think you are exempt from the community guidelines, simply because you don't like them.

[gryumov]

so please do not register your packages in General

Okay

[goerz]

Great. So can I close this?

[gryumov]

ok, close it

[goerz]

Please note that if you come around to the community guidelines in the future, you will always be welcome again