New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"fmt" name conflict between the new stdlib strformat and pre-existing lyro/strfmt #6958
Comments
Normally you'd be able to use e.g
It happens because Also: shouldn't the compiler warn that |
Me neither.
I hope the fix is not to disambiguate using something like |
you can write import strformat
template f(x: untyped): untyped =
strformat.fmt(x) btw. you write:
but effectively strformat.fmt mimics Python f-strings and strfmt.fmt mimics Python .format strfmt is excellent, except for its hand crafted formatting of floats which is broken: import strfmt
echo "{0:f}".fmt(1e20) produces this linenoise:
while import strformat
template f(x: untyped): untyped =
strformat.fmt(x)
echo f"{1e20:f}" produces:
I still would like to see someone coming up with a pure Nim (s)printf implementation. I have translated golang's strconv to Nim but i am unable to write golang's Sprintf accepting variadic arguments of any type ... |
It should be valid in
You are proving my point.. that this is already getting confusing :) Thanks, I will fix that statement in my main post above.
I haven't extensively used Are there some legal issues/politics that prevent lyro's |
the
is interesting. It works as long as you don't import strfmt. But as soon as you import strfmt it doesn't work even if you use strformat.fmt"{0} {s}" Thats because strformat.fmt"{0} {s}" finds and wants to call the procedure with this declaration: proc format*[T](x: T): string {.inline.} in strfmt. |
There is probably an issue for this already (assuming this is an issue), but shouldn't @kaushalmodi's code cause an "ambiguous error" at compile-time? If so then that's a wider issue with macros. As for renaming |
Macros are subject to overloading resolution. |
@Araq Are you saying that there is no conflict here then? |
It'll be great if the strfmt migrates into strformat, with conflicts solved as @kaushalmodi proposed |
Frank Fischer, the author of the older Can @dom96, @Araq or someone port that library into the Nim |
I don't understand why we need both in the standard library? The last time I checked |
@kaushalmodi AFAIK strformat does almost everything that strfmt does |
Maybe I can take care of this, if anyone is interested? |
IMO there is no need for another formatter in the stdlib, it would just be unnecessary bloat. That said, I think |
@ervinbosenbacher 👍 if you mean fixing the situation with the name collision so that both can be imported (maybe by using a different workaround in line 209 of strformat.nim). I'm not sure if renaming I doubt that @Araq is in favor of pulling |
I can fix the name collision problem then. |
From what I see, both libraries are implementing different features from Python. The I don't see any overlap between the two libraries except for the
That's a subjective opinion. At least love the Python
It does work fine. I just hope that it's not completely abandoned once it starts breaking because of some backward incompatible change in Nim core. The best thing to keep that package alive would be to port into Nim. The second best thing would be for someone from here to take up the package maintainership from the original author (because as I mentioned above, the original author is no longer using Nim, and so not interested in maintaining this package).
+++1 Please! Unlike the above opinion based thought, this is factual.. Both
Yes, anything else would work, but not
Thanks! |
@Yardanico ok on it. As my first contribution. |
Definitely let's not add yet another string formatting package into the stdlib, if you want to see |
@kaushalmodi but the point of f-strings is that you don't really need position-based placement |
@dom96 yes that is what I meant. Maintaining it and make sure that its not colliding with similar libraries. |
Anyway let me know, I can maintain it, bugfix it, etc. In python I am using heavily he ({}).format() facility so I am happy to contribute with the same thing to Nim. |
@dom96 I wish I could maintain it, but I don't have enough software programming skills to do that. So the best I can contribute to Nim at this point are by opening these issues that point out issues from outside the Nim box-view of the world. Having using Python, Perl, Matlab, Emacs lisp, Verilog, and many more languages for many years, I can easily see issues like inconsistencies and UX flaws in languages. But I am not a software developer, and don't understand the implementation level detail of any of these. I want to master user-level knowledge of Nim, but issues like this one come as stumbling blocks. @ervinbosenbacher Thanks for offering to take up maintainership of So you just need to get in touch with him, and talk you him that you are interested in taking up the maintainership if that package, and maybe forking it off to your own repo. |
To clarify on my suggestion about importing |
We shouldn't have two ways to do something. There should ideally be one way. What does To summarise, as far as I'm concerned, all that needs to be done for this issue is to rename |
I believe you are referring to the 3rd party, older That said, I respect the decision if the But coming back to facts, the Thanks! |
@dom96 Renaming |
@GULPF oh yes, I mentioned that in my comment as well (#6958 (comment)). So there are two issues here at least, apologies.
So please tell us what those uses are, so that we can figure out whether f-string can be improved to support them. |
Renaming import strfmt except format
import strformat
template f(x: untyped): untyped =
strformat.fmt(x)
echo f"{1e20:f}"
let s = "foobar"
echo f"{0}" IMO that's really good enough because nobody should import both at the same time. |
That's irrelevant. It should still be renamed. |
So why should it be renamed? And to what name? |
It should be renamed because it follows Python's f-string semantics (which use |
I disagree, |
@andreaferretti The compiler should be able to handle it, at least in theory. E.g these two examples works right now: import strformat
let fmt = "abc"
echo fmt"{fmt:>5}"
import strformat
proc fmt(): int = 2
echo fmt"{fmt()}" |
Well, but this doesn't import strformat
proc fmt(s: string): string = s & " formatted"
echo fmt"hello" |
Why does it have to be exactly It's very odd that both If renaming to And after the rename we should be able to use both string formatting implementations in Nim, right? |
I'm struggling to think of a single instance when I used |
I agree, that's sort of a Programming 101 failure. Why would anyone use single character functions in their code?? |
If another library has an echo function, then let's rename echo to e. |
The On the other hand I wouldn't be surprised if
If some library now creates a new /twocents |
A function called Even the Nim repo is not free of
|
Nim is older, much older and therefore libraries must be adapted. |
They can coexist, I showed you how. If you don't read what I write here, there is little reason for me to say anything furher here.
No, wrong (!!!!), because both |
@Araq You seem to agree with @andreaferretti that it shouldn't be renamed to |
How is there no conflict in presence of -say - |
There is in that case, just like there would be if that proc was named |
It is just that |
Just like they/we don't have to re-learn that Agreed with @bluenote10 and @andreaferretti that While I really like (and often use) Python's f-strings and I think it is a great syntax for Python, |
Everybody who uses Nim must be aware Nim is still at version 0.x and some breaking changes are expected to happen from time to time. (These should happen right now, rather than to either live with missed opportunities or to break things later (see Python 2 vs Python 3 endless dicussions)) Having good string formatting (which might incorporate some things (not just |
Hello,
I have been using the
strfmt
module by user lyro on bitbucket.The newly introduced
strformat
module also has the exact same named (fmt
) macro.Now the strformat
fmt
mimics Pythonf
-strings and the older strfmtfmt
mimics Python.format
. This is very confusing and conflicting (causes errors)! It is now not possible to import bothstrformat
andstrfmt
(these two are also too similarly named) and then use both styles offmt
in the same code.Below is an example of using the
fmt
from pre-existing strfmt by lyro:which outputs:
Now if I do:
I get:
Can the new strformat
fmt
be called justf
? If not that, then atleast notfmt
?Copying @vegansk (#5600) and @bluenote10 (#6507).
Update: Fix error in mentioning what was strformat
fmt
vs strfmtfmt
.The text was updated successfully, but these errors were encountered: