V0.6: isalpha (and similar) deprecation warning for arrays of (Sub)Strings

The following code results in a deprecation warning telling one to use all(isalpha, s) instead of isalpha(s):

julia> s = ["abc", "def", "ghi"]
3-element Array{String,1}:
 "abc"
 "def"
 "ghi"

julia> all(isalpha, s)
WARNING: isalpha(s::AbstractString) is deprecated, use all(isalpha, s) instead.
Stacktrace:
 [1] depwarn(::String, ::Symbol) at ./deprecated.jl:64
 [2] isalpha(::String) at ./deprecated.jl:51
 [3] all(::Base.UTF8proc.#isalpha, ::Array{String,1}) at ./reduce.jl:595
 [4] eval(::Module, ::Any) at ./boot.jl:235
 [5] eval_user_input(::Any, ::Base.REPL.REPLBackend) at ./REPL.jl:66
 [6] macro expansion at ./REPL.jl:97 [inlined]
 [7] (::Base.REPL.##1#2{Base.REPL.REPLBackend})() at ./event.jl:73
while loading no file, in expression starting on line 0
true

isalpha is called for every element of s, so it calls isalpha(::AbstractString) which rightfully results in a warning.
However, the warning itself is misleading imo, because all(isalpha, s) is already called and doesn’t explain the proper way to do this. It behaves the same for similar functions such as isdigit.

A working solution would be

julia> all(all(isalpha, x) for x in s)
true

Although I’m not sure if this is the best/most performant solution. Is there a better way to achieve this?

Not sure if this is a bug and belongs on the GitHub issue tracker instead. Imo there should be a different deprecation warning for all(isalpha, s::Array{AbstractString, 1}) that actually explains how to fix it.


julia> versioninfo()
Julia Version 0.6.0-pre.alpha.126
Commit 0615ea2b07* (2017-03-12 13:00 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.9.1 (ORCJIT, broadwell)

What the depwarn suggests is all(x->all(isalpha, x), s). I think it’s very hard for the depwarn to suggest anything better in this case without creating confusing in other cases. (e.g. suggesting replacing isalpha(s::AbstractString) with (x->all(isalpha, x))(s) can be more general but is unlikely helpful). The signature printed should help resolving the confusing though.

1 Like

That’s a better solution than the for-loop. Thanks for the quick response & explanation! :slight_smile: