I might be wrong but I believe this is a pre-commit issue.

I might be wrong but I believe this is a pre-commit issue.

Huh...weird.

@jack1142 But then why do other packages work with pre-commit? (e.g. pycln in my example)

@jack1142 The pre-commit author is saying it's most likely black's issue, so you guys are probably gonna have to hash this one out.

@jack1142 The pre-commit author is saying it's most likely black's issue, so you guys are probably gonna have to hash this one out.

Just a warning/heads-up; nothing more.

We could also consider blaming click, because click.echo is supposed to handle Unicode correctly for us: https://click.palletsprojects.com/en/7.x/api/#click.echo

@JelleZijlstra Who will submit the issue with click?

not sure if this is related, but i get broken emojis on windows command prompt:

.\black>py -m black ..\black_testo          
error: cannot format ..\black_testo\asd.py: Cannot parse: 3:12:     match x:dd

Oh no! 💥 💔 💥
1 file failed to reformat.

here it looks ok, but in pycharm it looks like this:

@JelleZijlstra Can you provide an update?

I don't have any insights to share.

Did you open an issue with click?

@ichard26 Can you provide insights?

Sadly no.

Sadly no.

Are there any black contributors who can help? Can someone be assigned to this?

This is a volunteer project and you can't expect anyone to pick this up spontaneously. Personally I am unlikely to do anything more here because I can't reproduce the problem (I don't even have Windows) and I don't think I will enjoy digging into it.

This is a volunteer project and you can't expect anyone to pick this up spontaneously.

@JelleZijlstra This issue has been open since July. I just mean is someone in charge of assigning tasks to contributors for the black project.

Not expecting anything, just asking. If no one can tackle this, I'll close with "won't fix". Is that alright?

Closing as a "won't fix".

This is a fairly hard problem to solve and is shows up when black (or any python program) is captured/redirected in anyway; black | more on Windows has the same problem.

This snippet from sys.stdout doc says what's happening:

     On Windows, UTF-8 is used for the console device.  Non-character
     devices such as disk files and pipes use the system locale
     encoding (i.e. the ANSI codepage).  Non-console character
     devices such as NUL (i.e. where ``isatty()`` returns ``True``) use the
     value of the console input and output codepages at startup,
     respectively for stdin and stdout/stderr. This defaults to the
     system :term:`locale encoding` if the process is not initially attached
     to a console.

For anyone else hitting this problem, the only possible fix I have found is to set PYTHONUTF8=1 in the your/the users environment.

Is it worth adding this as a note in the docs somewhere perhaps?

@ashb Thank you for looking at this and taking an interest. I appreciate you contributing your time.

In regards to the above, I have some remarks:

1. Nearly all other packages, e.g. pycln, do not experience problems with emojis out-of-the-box and do not require users to set PYTHONUTF8=1. It could be that pycln sets this environment variable programmatically under the hood in its source code, possibly like so:

import os

if os.name == 'nt':
   os.environ['PYTHONUTF8'] = 1

I mentioned pycln working out-of-the-box here: #3156 (comment)

If you are able and would like to, would you consider looking at packages like pycln that are working and see what they are doing in their source code? It would be best to use the same approach other working libraries are using.

2. I would not agree that requiring users set an environment variable manually is a long-term solution. Instead, if setting this environment variable is actually the required fix, I believe it should be implemented in a PR.

If are able to identify that other packages set PYTHONUTF8 programmatically, would you be willing to submit a PR to implement this fix?

@ashb I would also be willing to help you with a PR, should you need assistance. Please let me know if this is something you would like me to do.

Great to see progress being made here! I'm happy to review a PR if that's the outcome.

Sure I'll take a look at pycln and see what it does differently

Here is how pycln fixes it:

https://github.com/hadialqattan/pycln/blob/a9b8b0738caf181df649005e5a51c2b61c911852/pycln/__init__.py#L15-L20

Setting PYTHONUITF8 on a running process won't have any effect, the encoding of sys.std* is set very early on in the initalization of the python interpreter.

In #3374 I've done a similar fix to what pycln did. PTAL @JelleZijlstra

@adam-grant-hendry That is an unhelpful comment. I understand your frustration, but leaving the comment serves no purpose but to annoy others.

@adam-grant-hendry, man, don't be like that. Don't treat maintainers of an open-source project like they owe you anything. The license is pretty explicit about the reality of the situation. I don't like waving it in front of anybody's nose but it feels like you misunderstand your role.

The issue has been filed (thank you), and it's open until somebody with Windows will handle it. Maybe you? You can reproduce it and you clearly care about it.

So go and contribute. There's an open PR already. Check it out and confirm if it solves your problem. But definitely don't go and demand action, nor -- worse yet! -- second-guess integrity of the maintainers. That's no way to build long-term collaboration.

@ashb @ambv You are right: my comment was rude and unhelpful.

@JelleZijlstra I'm sorry for what I said. I deleted my last comment and hope you will accept my apology. Thank you for maintaining black and offering to review. I am truly sorry for being rude; it was uncalled for.