February 2026 - ruby-core - ml.ruby-lang.org

[ruby-core:124738] [Ruby Feature#6478] BasicObject#__class__
by Eregon (Benoit Daloze) 09 Feb '26

09 Feb '26

Issue #6478 has been updated by Eregon (Benoit Daloze). byroot (Jean Boussier) wrote in #note-18: > I mean, it's consistent with `__send__` and `__id__`, aliases of `send` and `object_id` meant to be used by generic code that want to ensure it can deal with any object, even ones that would redefine common methods. Yeah, I dislike those too 😅 Specifically I think it looks very unidiomatic (and ugly) when used in Ruby code. I think at least it's clear it's not good to go towards having every `Kernel` method as a `__x__` variant on BasicObject. Also even `__send__` and `__id__` can be redefined, so the `KERNEL_CLASS = Kernel.instance_method(:class); KERNEL_CLASS.bind_call(obj)` approach is in fact safer. So my take on this is `KERNEL_CLASS = Kernel.instance_method(:class); KERNEL_CLASS.bind_call(obj)` is good enough, and also most BasicObject subclasses should implement Kernel-like methods. Concrete examples from real code where this is not good enough would most likely be helpful to move this forward if people want that. ---------------------------------------- Feature #6478: BasicObject#__class__ https://bugs.ruby-lang.org/issues/6478#change-116339 * Author: trans (Thomas Sawyer) * Status: Feedback * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- How else is one supposed to get the class of a subclass of BasicObject? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124735] [Ruby Feature#6478] BasicObject#__class__
by byroot (Jean Boussier) 09 Feb '26

09 Feb '26

Issue #6478 has been updated by byroot (Jean Boussier). Not that I'm for nor against this feature request, but: > In terms of naming I think __class__ looks like a hack that Python would use and not Ruby-like. I mean, it's consistent with `__send__` and `__id__`, aliases of `send` and `object_id` meant to be used by generic code that want to ensure it can deal with any object, even ones that would redefine common methods. > Why not add BasicObject#class? I suspect that would break various proxy classes in gems. Might not be a huge deal. ---------------------------------------- Feature #6478: BasicObject#__class__ https://bugs.ruby-lang.org/issues/6478#change-116336 * Author: trans (Thomas Sawyer) * Status: Feedback * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- How else is one supposed to get the class of a subclass of BasicObject? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124734] [Ruby Feature#6478] BasicObject#__class__
by Eregon (Benoit Daloze) 09 Feb '26

09 Feb '26

Issue #6478 has been updated by Eregon (Benoit Daloze). In terms of naming I think `__class__` looks like a hack that Python would use and not Ruby-like. Why not add `BasicObject#class`? I think `Kernel.instance_method(:class).bind_call(o)` is fine for most cases. FWIW performance-wise on TruffleRuby there isn't much difference when storing the `UnboundMethod` in a constant: ``` truffleruby 33.0.1 (2026-01-20), like ruby 3.3.7, Oracle GraalVM Native [x86_64-linux] Calculating ------------------------------------- instance_method.bind_call 33.492M (± 3.0%) i/s (29.86 ns/i) - 169.962M in 5.079892s bind_call 631.582B (± 1.1%) i/s (0.00 ns/i) - 3.157T in 4.998908s __class__ 750.398B (± 1.3%) i/s (0.00 ns/i) - 3.751T in 4.999106s ``` BasicObject are very difficult to use because they miss so many "standard" methods from Kernel. As such I see them as mostly meant to proxy all the Kernel methods to maybe some delegate object or so, and the responsability of the BasicObject subclass to implement Kernel-like methods to make the object usable in normal Ruby code. ---------------------------------------- Feature #6478: BasicObject#__class__ https://bugs.ruby-lang.org/issues/6478#change-116335 * Author: trans (Thomas Sawyer) * Status: Feedback * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- How else is one supposed to get the class of a subclass of BasicObject? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121683] [Ruby Bug#21272] Class.new doesn't trigger :class TracePoint
by st0012 (Stan Lo) 09 Feb '26

09 Feb '26

Issue #21272 has been reported by st0012 (Stan Lo). ---------------------------------------- Bug #21272: Class.new doesn't trigger :class TracePoint https://bugs.ruby-lang.org/issues/21272 * Author: st0012 (Stan Lo) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- According to the official [documentation](https://docs.ruby-lang.org/en/master/TracePoint.html#class-T…: > To filter what is traced, you can pass any of the following as events: > > :class > Start a class or module definition. I'd expect `:class` events to be triggered when new classes are defined via `Class.new` as well, but currently that's not the case. Should we either support `Class.new`, or clarify the behaviour in documentation? ### Reproduction ```rb TracePoint.trace(:class) do |tp| puts "Class created at line: #{tp.lineno}" end class Foo; end # Triggers the tracepoint Baz = Class.new # Doesn't trigger the tracepoint # ruby test.rb # Class created at line: 5 ``` -- https://bugs.ruby-lang.org/

3 8

[ruby-core:124723] [Ruby Feature#6478] BasicObject#__class__
by jneen (Jeanine Adkisson) 09 Feb '26

09 Feb '26

Issue #6478 has been updated by jneen (Jeanine Adkisson). I wonder if exposing a static `Object.class_of(thing)` would be appropriate? There's also the singleton_class to consider as well. ---------------------------------------- Feature #6478: BasicObject#__class__ https://bugs.ruby-lang.org/issues/6478#change-116321 * Author: trans (Thomas Sawyer) * Status: Feedback * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- How else is one supposed to get the class of a subclass of BasicObject? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124721] [Ruby Feature#6478] BasicObject#__class__
by trinistr (Alexander Bulancov) 08 Feb '26

08 Feb '26

Issue #6478 has been updated by trinistr (Alexander Bulancov). I would like to revive discussion for this feature request as I feel that `BasicObject#__class_` is still needed. Note: obviously, it is possible to transplant methods with `define_method` (that is very nice!), but one doesn't always control the class of the object. **What for?** - Inspection of objects. Currently, it's not possible to print anything reasonable for a BasicObject-derived object. - Introspection. Everything in Ruby is an object with a class, and not being able to get that class is weird and painful. It's possible to use `Kernel.instance_method(:class).bind_call(o)`, but why is this even required? It's very un-ergonomical. **Why?** 1. Printing of classes is especially useful for error messages, and Ruby's internals can just do that (though maybe this is also just `Kernel#class`?): ```ruby class A < BasicObject; end 1.clone(freeze: A.new) # in 'Numeric#clone': unexpected value for freeze: A (ArgumentError) ``` Creating such messages in regular code is unnecessarily hard when any object can happen, it requires conditionals and/or using the `bind_call` trick. 2. Getting a class of an object is probably mostly useful for interactive use (which is still important), but the long incantation to do it is inconvenient and hard to remember as something that can be done. 3. `bind_call` is an order of magnitude slower than just using the method: ```ruby class B < BasicObject; define_method(:__class__, ::Kernel.instance_method(:class)); end b = B.new class_method = Kernel.instance_method(:class) Benchmark.ips { |x| x.report("instance_method.bind_call") { Kernel.instance_method(:class).bind_call(b) } x.report("bind_call") { class_method.bind_call(b) } x.report("__class__") { b.__class__ } } ruby 3.4.8 (2025-12-17 revision 995b59f666) +PRISM [x86_64-linux] Warming up -------------------------------------- instance_method.bind_call 107.359k i/100ms bind_call 119.100k i/100ms __class__ 2.187M i/100ms Calculating ------------------------------------- instance_method.bind_call 1.022M (± 3.3%) i/s (978.28 ns/i) - 5.153M in 5.046952s bind_call 1.147M (± 4.6%) i/s (871.47 ns/i) - 5.836M in 5.096893s __class__ 22.494M (± 3.6%) i/s (44.46 ns/i) - 113.699M in 5.062084s ``` **Compatibility** I believe virtually no code would be negatively impacted by addition of `BasicObject#__class__`. Code would need to both check for the presence of `#__class__` and do something completely divorced from `#class` to be affected. On the other hand, it would allow for a method that doesn't conflict with a keyword. Searching for uses of `__class__` on GitHub (https://github.com/search?q=__class__+language%3Aruby&ref=searchresults&typ…) seems to show just a few current uses: - defining `__class__` to refer to the class of a proxy object itself - `alias __class__ class`, seemingly to call directly instead of `self.class` - Rubinius has it (https://github.com/rubinius/rubinius/blob/84368419a49767ef9549a5778812e5f54…) - Pythonification There are some results that define `__class__` if it doesn't exist already, but those should not be impacted, as the meaning would be the same. **In short** Adding `BasicObject#__class__` would - make it possible to always get the class for any object in the same way; - be faster than current solution; - have no negative impact on existing codebase. ---------------------------------------- Feature #6478: BasicObject#__class__ https://bugs.ruby-lang.org/issues/6478#change-116318 * Author: trans (Thomas Sawyer) * Status: Feedback * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- How else is one supposed to get the class of a subclass of BasicObject? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118784] [Ruby master Feature#20664] Add `before` and `until` options to Enumerator.produce
by knu (Akinori MUSHA) 08 Feb '26

08 Feb '26

Issue #20664 has been reported by knu (Akinori MUSHA). ---------------------------------------- Feature #20664: Add `before` and `until` options to Enumerator.produce https://bugs.ruby-lang.org/issues/20664 * Author: knu (Akinori MUSHA) * Status: Open ---------------------------------------- Enumerator.produce provides a nice way to generate an infinite sequence but is a bit awkward to define how to end a sequence. It lacks a simple and easy way to produce typical finite sequences in an intuitive syntax. This proposal attempts to solve the problem by adding these two options to the method: - `before`: when provided, it is used as a predicate to determine if an iteration should end before a generated value gets yielded. - `until`: when provided, it is used as a predicate to determine if an iteration should end until after a generated value gets yielded. Any value that responds to `to_proc` and returns a `Proc` object is accepted in these options. A typical use case for the `before` option is traversing a tree structure to iterate over the ancestors or following/preceding siblings of a node. The `until` option can be used when there is a clear definition of the "last" value to yield. ```ruby enum = Enumerator.produce(File, before: :nil?, &:superclass) enum.to_a #=> [File, IO, Object, BasicObject] enum = Enumerator.produce(3, until: :zero?, &:pred) enum_to_a #=> [3, 2, 1, 0] ``` ---Files-------------------------------- 0001-Add-before-and-until-options-to-Enumerator.produce.patch (10.7 KB) -- https://bugs.ruby-lang.org/

6 12

[ruby-core:122842] [Ruby Feature#21518] Statistical helpers to `Enumerable`
by Amitleshed (Amit Leshed) 07 Feb '26

07 Feb '26

Issue #21518 has been reported by Amitleshed (Amit Leshed). ---------------------------------------- Feature #21518: Statistical helpers to `Enumerable` https://bugs.ruby-lang.org/issues/21518 * Author: Amitleshed (Amit Leshed) * Status: Open ---------------------------------------- **Summary** I'd like to add two statistical helpers to `Enumerable`: - `Enumerable#average` (arithmetic mean) - `Enumerable#median` Both are small, well-defined operations that many Rubyists re-implement in apps and gems. Providing them in core avoids repeated, ad-hoc code and aligns with `Enumerable#sum`, which Ruby already ships. **Motivation** - These are among the most common “roll-your-own” helpers for arrays/ranges of numbers. - They are conceptually simple, universally useful beyond web/Rails. - Similar to `sum`, they’re primitives for quick data analysis, ETL scripts, CLI tooling, etc. - Including them encourages consistent semantics (what to do with empty sets, mixed numerics, etc.). ## Proposed API & Semantics ```ruby Enumerable#average -> Float or nil Enumerable#median -> Numeric or nil ``` ```ruby [1, 2, 3, 4].average # => 2.5 (1..4).average # => 2.5 [].average # => nil [1, 3, 2].median # => 2 [1, 2, 3, 10].median # => 2.5 (1..6).median # => 3.5 [].median # => nil ``` Ruby implementation ```ruby module Enumerable def average count = 0 total = 0.0 each do |x| raise TypeError, "non-numeric value for average" unless x.is_a?(Numeric) total += x count += 1 end count.zero? ? nil : total / count end def median arr = to_a return nil if arr.empty? arr.each { |x| raise TypeError, "non-numeric value for median" unless x.is_a?(Numeric) } arr.sort! mid = arr.length / 2 arr.length.odd? ? arr[mid] : (arr[mid - 1] + arr[mid]) / 2.0 end end ``` **Upon approval I'm more than willing to implement spec and code in C.** -- https://bugs.ruby-lang.org/

9 12

[ruby-core:124709] [Ruby Bug#21868] Prism doesn't use the ruby allocator
by byroot (Jean Boussier) 07 Feb '26

07 Feb '26

Issue #21868 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21868: Prism doesn't use the ruby allocator https://bugs.ruby-lang.org/issues/21868 * Author: byroot (Jean Boussier) * Status: Open * Assignee: prism * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I discovered this while working on the internal side of [Feature #21861] (https://github.com/ruby/ruby/pull/15989) Prism doesn't use `ruby_xmalloc`, but raw `malloc`. I tried to fix it myself, but couldn't figure out the solution, so I left some FIXME comments: - https://github.com/ruby/ruby/blob/d066b9e01ccb2260fac8b2580c10e73335c7c7db/… - https://github.com/ruby/ruby/blob/d066b9e01ccb2260fac8b2580c10e73335c7c7db/… I'd appreciate if someone from the Prism team could look at it. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121982] [Ruby Bug#21323] irb fails to start with Namespace
by Eregon (Benoit Daloze) 07 Feb '26

07 Feb '26

Issue #21323 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21323: irb fails to start with Namespace https://bugs.ruby-lang.org/issues/21323 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-10T07:50:29Z namespace-on-read-.. bd4f57f96b) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` $ irb irb(main):001> 6 * 7 => 42 $ RUBY_NAMESPACE=1 irb /home/eregon/prefix/ruby-master/bin/ruby: warning: Namespace is experimental, and the behavior may change in the future! See doc/namespace.md for know issues, etc. /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/did_you_mean/core_ext/name_error.rb:11: warning: irb is not part of the default gems since Ruby 3.5.0. Install irb from RubyGems. /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/did_you_mean/core_ext/name_error.rb:11: warning: irb is not part of the default gems since Ruby 3.5.0. Install irb from RubyGems. <internal:/home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_require.rb>:141:in 'Kernel#require': cannot load such file -- irb (LoadError) Did you mean? erb from <internal:/home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_require.rb>:141:in 'Kernel#require' from /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+0/gems/irb-1.15.2/exe/irb:7:in 'Namespace::Loader#require' from /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+0/gems/irb-1.15.2/exe/irb:7:in '<top (required)>' from /home/eregon/.rubies/ruby-master/bin/irb:25:in 'Kernel#load' from /home/eregon/.rubies/ruby-master/bin/irb:25:in 'Namespace::Loader#load' from /home/eregon/.rubies/ruby-master/bin/irb:25:in '<main>' <internal:/home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require': cannot load such file -- irb (LoadError) Did you mean? erb from <internal:/home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+0/gems/irb-1.15.2/exe/irb:7:in 'Namespace::Loader#require' from /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+0/gems/irb-1.15.2/exe/irb:7:in '<top (required)>' from /home/eregon/.rubies/ruby-master/bin/irb:25:in 'Kernel#load' from /home/eregon/.rubies/ruby-master/bin/irb:25:in 'Namespace::Loader#load' from /home/eregon/.rubies/ruby-master/bin/irb:25:in '<main>' zsh: exit 1 RUBY_NAMESPACE=1 irb ``` -- https://bugs.ruby-lang.org/

3 5