Skip to content
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

Revert "Deprecate DevNull, STDIN, STDOUT, and STDERR to lowercase" #26636

Closed
wants to merge 1 commit into from

Conversation

ararslan
Copy link
Member

This reverts PR #25959. Lowercasing these identifiers conflicts with the statistical meaning of stderr, i.e. the standard error. This is defined in StatsBase and widely used.

…5959)"

This reverts commit 446085a.
Lowercasing these identifiers conflicts with the statistical meaning of
`stderr`, i.e. the standard error. This is defined in StatsBase and
widely used.
@iamed2
Copy link
Contributor

iamed2 commented Mar 27, 2018

Can we just not export them?

stderr search on Google waits until the 3rd page to show the statistical meaning. The next use was on page 7.

@StefanKarpinski
Copy link
Member

IO.stderr, IO.devnull, etc. would be pretty good imo but IO is already a type so we either need a different name or some more name shuffling...

@KristofferC
Copy link
Member

@iamed2
Copy link
Contributor

iamed2 commented Mar 27, 2018

Python puts them in sys, maybe Base.Sys.stderr?

@StefanKarpinski
Copy link
Member

Sure, that would be a good place for them.

@JeffBezanson
Copy link
Member

These seem much more important than most of the Sys module --- you need the standard error stream far more often than you need to know e.g. which model of CPU you have.

@StefanKarpinski
Copy link
Member

The idea behind putting them in Sys is not because they're less important but to avoid taking a name that is commonly used in statistics.

@JeffBezanson
Copy link
Member

I really don't think they fit in that module though. Everything else in Sys is basically hardware and OS reflection, nothing like critical I/O functionality.

@iamed2
Copy link
Contributor

iamed2 commented Mar 27, 2018

Has anyone felt the desire for an IO-related module for other reasons? Maybe it would be useful for other things.

@mbauman
Copy link
Member

mbauman commented Mar 27, 2018

julia> Base.getproperty(::Type{IO}, s::Symbol) = s == :stdout ? Base.stdout : s == :stderr ? Base.stderr : throw(ArgumentError())

julia> IO.stderr
Base.TTY(RawFD(0x0000000f) open, 0 bytes waiting)

julia> show(IO.stderr, "HAHAHA")
"HAHAHA"

@JeffBezanson
Copy link
Member

😅

@nalimilan
Copy link
Member

nalimilan commented Mar 28, 2018

https://docs.scipy.org/doc/scipy-0.14.0/reference/generated/scipy.stats.sem.html

Note that the SciPy stats.stderr function was deprecated in favor of stats.sem. sem is pretty short, but it doesn't seem terrible to do some sort of renaming in StatsBase. I suppose it makes the deprecation process more painful, however. (From #25959 (comment))

@KristofferC @stevengj That's a different thing. stderr in StatsBase returns the standard error of the model coefficients, not of the mean. So it's more general (and could be used in other contexts than modeling). A possible name would be se, but it's quite short. ste would be consistent with std, but it's less standard. EDIT: we could also rename std to sd (which is the name used e.g. by R) and stderr to se.

@ararslan ararslan added the triage This should be discussed on a triage call label Mar 28, 2018
@KristofferC
Copy link
Member

ste sounds good.

@stevengj
Copy link
Member

stevengj commented Mar 28, 2018

The stdio streams are used a lot more than the standard error function in programming, so it doesn't seem crazy that the latter should be the one to be renamed. There are lots of reasonable options, e.g. you could just use stderror — lengthening it seems preferable to shortening it to an inscrutable abbreviation like se.

@ararslan
Copy link
Member Author

Triage says rename the stats function.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants