[#102393] [Ruby master Feature#17608] Compact and sum in one step — sawadatsuyoshi@...

Issue #17608 has been reported by sawa (Tsuyoshi Sawada).

13 messages 2021/02/04

[#102438] [Ruby master Bug#17619] if false foo=42; end creates a foo local variable set to nil — pkmuldoon@...

Issue #17619 has been reported by pkmuldoon (Phil Muldoon).

10 messages 2021/02/10

[#102631] [Ruby master Feature#17660] Expose information about which basic methods have been redefined — tenderlove@...

Issue #17660 has been reported by tenderlovemaking (Aaron Patterson).

9 messages 2021/02/27

[#102639] [Ruby master Misc#17662] The herdoc pattern used in tests does not syntax highlight correctly in many editors — eregontp@...

Issue #17662 has been reported by Eregon (Benoit Daloze).

13 messages 2021/02/27

[#102652] [Ruby master Bug#17664] Behavior of sockets changed in Ruby 3.0 to non-blocking — ciconia@...

Issue #17664 has been reported by ciconia (Sharon Rosner).

23 messages 2021/02/28

[ruby-core:102535] [Ruby master Misc#17591] Test frameworks and REPLs do not show deprecation warnings by default

From: eregontp@...
Date: 2021-02-16 12:26:35 UTC
List: ruby-core #102535
Issue #17591 has been updated by Eregon (Benoit Daloze).


aycabta (aycabta .) wrote in #note-6:
> IRB is often used by beginners for learning purposes, so I disagree.

I think a warning when using an experimental feature in IRB is a good thing.
For example, if one uses Ractor and that later leads to a SEGV, as least there is hint, vs not showing anything, which the user will likely blame on IRB.

IRB is also used by experienced Rubyists to see if a given approach works well.
In that case I think it is important to show deprecation warnings, as they might need to reconsider the approach based on that.

Maybe @akr can comment too, since he suggested irb/pry should show deprecation warnings? (in https://bugs.ruby-lang.org/issues/16345#note-31)

----------------------------------------
Misc #17591: Test frameworks and REPLs do not show deprecation warnings by default
https://bugs.ruby-lang.org/issues/17591#change-90435

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
----------------------------------------
Various people in #16345 said that:
> The issue can be mitigated if all test frameworks enable all deprecation warnings.
> The developer's practice can be supported by tools, such as test frameworks enable deprecation warnings automatically.

And this was used as a base to disable deprecation warnings by default in Ruby 2.7.2.

However, it seems no test frameworks or REPLs actually show deprecation warnings by default!
So Ruby developers will typically never see deprecation warnings for keyword arguments, and it will just break when they try Ruby 3.0.

I think only MSpec does `Warning[:deprecated] = true`, whether or not `-w` is passed, which seems the right thing to do.

Currently, RSpec enables `Warning[:deprecated] = true` only for `rspec -w`.

Same for `test/unit` 3.3.4 shipped with 2.7.2.

IRB in 2.7.2 does not show deprecated warnings.
Same for `pry`.

I think ruby-core needs to have a clear message here, like:
> All test frameworks and REPLs should include this snippet and run it before running tests: `Warning[:deprecated] = true if Warning.respond_to?(:[]=)`.
> This is important so that developers see warnings in development, and that they see the warnings before updating to the next Ruby version.
> Developers can choose to disable deprecation warnings explicitly if they want with `Warning[:deprecated] = false`.

And I think it would be good that ruby-core makes a PR or an issue to the main test frameworks/REPLs to show examples.

P.S.: if someone wants to disable all warnings with `-W0` or `$VERBOSE = nil`, it will indeed disable them all, including deprecation warnings, so there is no need to check `$VERBOSE` for setting `Warning[:deprecated] = true`.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

In This Thread