sub begin_work {
    use Data::Dumper;

    ... lotsa code

    no Data::Dumper;
    return;
}
[download]

This doesn't address your immediate problem, but application code modules like Data::Dumper do not follow the lexical scoping rules that pragma modules like strict, warnings and integer follow.

The effects of the use Data::Dumper; statement are seen from the point in the file at which the module is use-ed at compile time and in all code beyond that point.

Win8 Strawberry 5.8.9.5 (32)  Sun 01/10/2021 10:52:26
C:\@Work\Perl\monks
>perl -Mstrict -Mwarnings
# pm#11126693

foo();  # try disabling this statement

print Dumper [ qw(1 2 3) ];  # print() on unopened filehandle Dumper

# foo();  # try enabling this statement

sub foo {
    use Data::Dumper;
    print Dumper [ qw(a b c) ];

    no Data::Dumper;  # has no effect
    print Dumper [ qw(x y z) ];
    }

print Dumper [ qw(9 8 7) ];  # prints as expected
^Z
$VAR1 = [
          'a',
          'b',
          'c'
        ];
$VAR1 = [
          'x',
          'y',
          'z'
        ];
print() on unopened filehandle Dumper at - line 5.
$VAR1 = [
          '9',
          '8',
          '7'
        ];
[download]

Same results running under Perl version 5.30.3.1.

Update: Another little twist to consider is the effect of adding a declaration of the Dumper subroutine in the main package before the first call to Dumper (and before the use Data::Dumper; statement):

sub Dumper;

print Dumper [ qw(1 2 3) ];  # print() on unopened filehandle Dumper
[download]

What happens and why? Is there another way to identify Dumper to the compiler as a subroutine? What would happen if one wrote:

### sub Dumper;

print Dumper([ qw(1 2 3) ]);  # print() on unopened filehandle Dumper
[download]

(I see the same results under both versions 5.8.9 and 5.30.3.)