python-patterns/docs/python/module-globals/index.html at master · esbeetech/python-patterns

History

565 lines (562 loc) · 37.2 KB

Raw

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

299

300

301

302

303

304

305

306

307

308

309

310

311

312

313

314

315

316

317

318

319

320

321

322

323

324

325

326

327

328

329

330

331

332

333

334

335

336

337

338

339

340

341

342

343

344

345

346

347

348

349

350

351

352

353

354

355

356

357

358

359

360

361

362

363

364

365

366

367

368

369

370

371

372

373

374

375

376

377

378

379

380

381

382

383

384

385

386

387

388

389

390

391

392

393

394

395

396

397

398

399

400

401

402

403

404

405

406

407

408

409

410

411

412

413

414

415

416

417

418

419

420

421

422

423

424

425

426

427

428

429

430

431

432

433

434

435

436

437

438

439

440

441

442

443

444

445

446

447

448

449

450

451

452

453

454

455

456

457

458

459

460

461

462

463

464

465

466

467

468

469

470

471

472

473

474

475

476

477

478

479

480

481

482

483

484

485

486

487

488

489

490

491

492

493

494

495

496

497

498

499

500

501

502

503

504

505

506

507

508

509

510

511

512

513

514

515

516

517

518

519

520

521

522

523

524

525

526

527

528

529

530

531

532

533

534

535

536

537

538

539

540

541

542

543

544

545

546

547

548

549

550

551

552

553

554

555

556

557

558

559

560

561

562

563

564

565

<!doctype html>

<html>

<head>

<title>The Global Object Pattern</title>

href="../../_static/style.css">

</head>

<body>

•

•

<h1>The Global Object Pattern<a class="headerlink" href="#the-global-object-pattern" title="Permalink to this headline">¶</a></h1>

Verdict

Like several other scripting languages,

Python parses the outer level of each module as normal code.

Un-indented assignment statements, expressions,

and even loops and conditionals

will execute as the module is imported.

This presents an excellent opportunity

to supplement a module’s classes and functions

with constants and data structures that callers will find useful —

but also offers dangerous temptations:

mutable global objects can wind up coupling distant code,

and I/O operations impose import-time expense and side effects.

</div>

Every Python module is a separate namespace.

A module like <code class="docutils literal notranslate">json</code> can offer a <code class="docutils literal notranslate">loads()</code> function

without conflicting with, replacing, or overwriting

the completely different <code class="docutils literal notranslate">loads()</code> function

defined over in the <code class="docutils literal notranslate">pickle</code> module.

Separate namespaces are crucial to making a programming language tractable.

If Python modules were not separate namespaces,

you would be unable to read or write Python code

by keeping your attention focused on the module in front of you —

a line of code might use, or accidentally conflict with,

a name defined anywhere else in the Standard Library

or a third-party module you have installed.

Upgrading a third-party module could break your entire program

if the new version defined a new global that conflicted with yours.

Programmers who are forced to code in a language without namespaces

soon find themselves festooning global names

with prefixes, suffixes, and extra punctuation

in a desperate race to keep them from conflicting.

While every function and class is, of course, an object —

in Python, everything is an object —

the Module Global pattern more specifically refers

to normal object instances

that are given names at the global level of a module.

Two patterns use Module Globals

but are important enough to warrant their own articles:

<li><a class="reference internal" href="../prebound-methods/">Prebound Methods</a>

are generated when a module builds an object

and then assigns one or more of the object’s bound methods

to names at the module’s global level.

The names can be used to call the methods later

without needing to find the object itself.</li>

<li>While a <a class="reference internal" href="../sentinel-object/">Sentinel Object</a>

doesn’t have to live in a module’s global namespace —

some sentinel objects are defined as class attributes,

while others are private and live inside of a closure —

many sentinels, both in the Standard Library and beyond,

are defined and accessed as module globals.</li>

</ul>

This article will cover some other common cases.

<h2>The Constant Pattern<a class="headerlink" href="#the-constant-pattern" title="Permalink to this headline">¶</a></h2>

Modules often assign useful numbers, strings, and other values

to names in their global scope.

The Standard Library includes many such assignments,

from which we can excerpt a few examples.

<div class="highlight-default notranslate"><div class="highlight"><pre>January = 1 # calendar.py

WARNING = 30 # logging.py

MAX_INTERPOLATION_DEPTH = 10 # configparser.py

SSL_HANDSHAKE_TIMEOUT = 60.0 # asyncio.constants.py

TICK = "'" # email.utils.py

CRLF = "\r\n" # smtplib.py

</pre></div>

</div>

Remember that these are “constants” only in the sense

that the objects themselves are immutable.

The names can still be reassigned.

<div class="highlight-python notranslate"><div class="highlight"><pre>import calendar

calendar.January = 13

print(calendar.January)

</pre></div>

</div>

<div class="highlight-none notranslate"><div class="highlight"><pre>13

</pre></div>

</div>

Or deleted, for that matter.

<div class="highlight-python notranslate"><div class="highlight"><pre>del calendar.January

print(calendar.January)

</pre></div>

</div>

<div class="highlight-none notranslate"><div class="highlight"><pre>Traceback (most recent call last):

...

AttributeError: module 'calendar' has no attribute 'January'

</pre></div>

</div>

In addition to integers, floats, and strings,

constants also include immutable containers like tuples and frozen sets:

<div class="highlight-default notranslate"><div class="highlight"><pre>all_errors = (Error, OSError, EOFError) # ftplib.py

bytes_types = (bytes, bytearray) # pickle.py

DIGITS = frozenset("0123456789") # sre_parse.py

</pre></div>

</div>

More specialized immutable data types also serve as constants:

<div class="highlight-default notranslate"><div class="highlight"><pre>_EPOCH = datetime(1970, 1, 1, tzinfo=timezone.utc) # datetime

</pre></div>

</div>

On rare occasions,

a module global

which the code clearly never intends to modify

uses a mutable data structure anyway.

Plain mutable sets

are common in code that pre-dates the invention of the <code class="docutils literal notranslate">frozenset</code>.

Dictionaries are still used today

because, alas, the Standard Library doesn’t offer a frozen dictionary.

<div class="highlight-default notranslate"><div class="highlight"><pre># socket.py

_blocking_errnos = { EAGAIN, EWOULDBLOCK }

</pre></div>

</div>

<div class="highlight-default notranslate"><div class="highlight"><pre># locale.py

windows_locale = {

0x0436: "af_ZA", # Afrikaans

0x041c: "sq_AL", # Albanian

0x0484: "gsw_FR",# Alsatian - France

...

0x0435: "zu_ZA", # Zulu

}

</pre></div>

</div>

Constants are often introduced as a refactoring:

the programmer notices that the same value <code class="docutils literal notranslate">60.0</code>

is appearing repeatedly in their code,

and so introduces a constant <code class="docutils literal notranslate">SSL_HANDSHAKE_TIMEOUT</code>

for the value instead.

Each use of the name

will now incur the slight cost of a search into the global scope,

but this is balanced by a couple of advantages.

The constant’s name now documents the value’s meaning,

improving the code’s readability.

And the constant’s assignment statement

now provides a single location

where the value can be edited in the future

without needing to hunt through the code for each place <code class="docutils literal notranslate">60.0</code> was used.

These advantages are weighty enough

that a constant is sometimes introduced

even for a value that’s used only once,

hoisting a literal that was hidden deep in the code

up into visibility as a global.

Some programmers place constant assignments

close to the code that use them;

others put all constants at the top of the file.

Unless a constant is placed so close to its code

that it will always be in view of human readers,

it can be more friendly to put constants at the top of the module

for the easy reference of readers

who haven’t yet configured their editors to support jump-to-definition.

Another kind of constant is not directed inwards,

towards the code in the module itself,

but outwards as part of the module’s advertised API.

A constant like <code class="docutils literal notranslate">WARNING</code> from the <code class="docutils literal notranslate">logging</code> module

offers the advantages of a constant to the caller:

code will be more readable,

and the constant’s value could be adjusted later

without every caller needing to edit their code.

You might expect that a constant intended for the module’s own use,

but not intended for callers,

would always start with an underscore to mark it private.

But Python programmers are not consistent in marking constants private,

perhaps because the cost of needing to keep a constant around forever

because a caller might have decided to start using it

is smaller than the cost of having

a helper function or class’s API forever locked up.

</div>

<h2>Import-time computation<a class="headerlink" href="#import-time-computation" title="Permalink to this headline">¶</a></h2>

Sometimes constants are introduced for efficiency,

to avoid recomputing a value every time code is called.

For example,

even though math operations involving literal numbers

are in fact optimized away in all modern Python implementations,

developers often still feel more comfortable

making it explicit that the math should be done at import time

by assigning the result to a module global:

<div class="highlight-default notranslate"><div class="highlight"><pre># zipfile.py

ZIP_FILECOUNT_LIMIT = (1 << 16) - 1

</pre></div>

</div>

When the math expression is complicated,

assigning a name also enhances the code’s readability.

As another example,

there exist special floating point values

that cannot be written in Python as literals;

they can only be generated by passing a string to the float type.

To avoid calling <code class="docutils literal notranslate">float()</code> with <code class="docutils literal notranslate">'nan'</code> or <code class="docutils literal notranslate">'inf'</code>

every single time such a value is needed,

modules often build such values only once as module globals.

<div class="highlight-default notranslate"><div class="highlight"><pre># encoder.py

INFINITY = float('inf')

</pre></div>

</div>

A constant can also capture the result of a conditional

to avoid re-evaluating it each time the value is needed —

as long, of course, as the condition

won’t be changing while the program is running.

<div class="highlight-default notranslate"><div class="highlight"><pre># shutil.py

COPY_BUFSIZE = 1024 * 1024 if _WINDOWS else 16 * 1024

</pre></div>

</div>

My favorite example of computed constants in the Standard Library

is the <code class="docutils literal notranslate">types</code> module.

I had always assumed it was implemented in C,

to gain special access to built-in type objects like <code class="docutils literal notranslate">FunctionType</code>

and <code class="docutils literal notranslate">LambdaType</code> that are defined by the language implementation itself.

It turns out? I was wrong. The <code class="docutils literal notranslate">types</code> module is written in plain Python!

Without any special access to language internals,

it does what anyone else would do to learn what type functions have.

It creates a function, then asks its type:

<div class="highlight-default notranslate"><div class="highlight"><pre># types.py

def _f(): pass

FunctionType = type(_f)

</pre></div>

</div>

On the one hand,

this makes the <code class="docutils literal notranslate">types</code> module seem almost superfluous —

you could always use the same trick to discover <code class="docutils literal notranslate">FunctionType</code> yourself.

But on the other hand,

importing it from <code class="docutils literal notranslate">types</code>

lets both major benefits of the Constant Pattern shine:

code becomes more readable

because <code class="docutils literal notranslate">FunctionType</code> will have the same name everywhere,

and more efficient

because the constant only needs to be computed once

no matter how many modules in a large system might use it.

</div>

<h2>Dunder Constants<a class="headerlink" href="#dunder-constants" title="Permalink to this headline">¶</a></h2>

A special case of constants defined at a module’s global level

are “dunder” constants whose names start and end with double underscores.

Several Module Global dunder constants are set by the language itself.

For the official list,

look for the “Modules” subheading in the Python Reference’s section on

<a class="reference external" href="https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy">the standard type hierarchy</a>.

The two encountered most often are <code class="docutils literal notranslate">__name__</code>,

which programs need to check because of Python’s awful design decision

to assign the fake name <code class="docutils literal notranslate">'__main__'</code>

to the module invoked from the command line,

and <code class="docutils literal notranslate">__file__</code>,

the full filesystem path to the module’s Python file itself —

which is almost universally used to find data files included in a package,

even though the official recommendation these days

is to use <a class="reference external" href="https://docs.python.org/3/library/pkgutil.html#pkgutil.get_data"><code class="docutils literal notranslate">pkgutil.get_data()</code></a> instead.

<div class="highlight-default notranslate"><div class="highlight"><pre>here = os.path.dirname(__file__)

</pre></div>

</div>

Beyond the dunder constants set by the language runtime,

there is one Python recognizes if a module chooses to set it:

if <code class="docutils literal notranslate">__all__</code> is assigned a sequence of identifiers,

then only those names will be imported into another module

that does <code class="docutils literal notranslate">from … import *</code>.

You might have expected <code class="docutils literal notranslate">__all__</code> to become less popular

as <code class="docutils literal notranslate">import *</code> gained a reputation as an anti-pattern,

but it has gained a happy second career

limiting the list of symbols included

by automatic documentation engines like

<a class="reference external" href="http://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html">Sphinx autodoc module</a>.

Even though most modules never plan to modify <code class="docutils literal notranslate">__all__</code>,

they inexplicably specify it as a Python list.

It is more elegant to use a tuple.

Beyond these official dunder constants,

some modules —

despite unattractive how many people find dunder names —

indulge in the creation of even more.

Assignments to names like <code class="docutils literal notranslate">__author__</code> and <code class="docutils literal notranslate">__version__</code>

are scattered across the Standard Library and beyond.

While they don’t appear consistently enough

for tooling can assume their presence,

occasional readers probably find them informative,

and they’re easier to get to than official package metadata.

Beware that there does not seem to be agreement,

even within the Standard Library,

about what type <code class="docutils literal notranslate">__author__</code> should have.

<div class="highlight-default notranslate"><div class="highlight"><pre># bz2.py

__author__ = "Nadeem Vawda <[email protected]>"

</pre></div>

</div>

<div class="highlight-default notranslate"><div class="highlight"><pre># inspect.py

__author__ = ('Ka-Ping Yee <[email protected]>',

'Yury Selivanov <[email protected]>')

</pre></div>

</div>

Why not <code class="docutils literal notranslate">author</code> and <code class="docutils literal notranslate">version</code> instead, without the dunders?

An early reader probably misunderstood dunders,

which really meant “special to the Python language runtime,”

as a vague indication

that a value was module metadata rather than module code.

A few Standard Library modules do offer their version without dunders,

but without even agreeing on the capitalization.

<div class="highlight-default notranslate"><div class="highlight"><pre>VERSION = "1.3.0" # etree/ElementTree.py

version = "0.20" # sax/expatreader.py

version = "0.9.0" # tarfile.py

</pre></div>

</div>

To avoid the inconsistencies surrounding

these informal and ad-hoc metadata conventions,

a package that expects to be installed with <code class="docutils literal notranslate">pip</code>

can learn the names and versions of other installed packages

directly from the Python package installation system.

More information is available in the <a class="reference external" href="https://setuptools.readthedocs.io/en/latest/pkg_resources.html">setuptools documentation on the <code class="docutils literal notranslate">pkg_resources</code> module</a>.

</div>

<h2>The Global Object Pattern<a class="headerlink" href="#id1" title="Permalink to this headline">¶</a></h2>

In the full-fledged Global Object pattern,

as in the Constant pattern,

a module instantiates an object at import time

and assigns it a name in the module’s global scope.

But the object does not simply serve as data;

it is not merely an integer, string, or data structure.

Instead, the object is made available

for the sake of the methods it offers — for the actions it can perform.

The simplest Global Objects are immutable.

A common example is a compiled regular expression —

here are a few examples from the Standard Library:

<div class="highlight-default notranslate"><div class="highlight"><pre>escapesre = re.compile(r'[\\"]') # email/utils.py

magic_check = re.compile('([*?[])') # glob.py

commentclose = re.compile(r'--\s*>') # html/parser.py

HAS_UTF8 = re.compile(b'[\x80-\xff]') # json/encoder.py

</pre></div>

</div>

Compiling a regular expression as a module global

is a good example of the more general Global Object pattern.

It achieves an elegant and safe transfer of expense

from later in a program’s runtime to import time instead.

The tradeoffs are:

<li>The cost of importing the module increases

by the cost of compiling the regular expression

(plus the tiny cost of assigning it to a global name).</li>

<li>The import-time cost is now borne by every program that imports the module.

Even if a program doesn’t happen to call any code

that uses the <code class="docutils literal notranslate">HAS_UTF8</code> regular expression shown above,

it will incur the expense of compiling it

whenever it imports the <code class="docutils literal notranslate">json</code> module.

(Plot twist: in Python 3, the pattern is no longer even used in the module!

But its name was not marked private with a leading underscore,

so I suppose it’s not safe to remove —

and every <code class="docutils literal notranslate">import json</code> gets to pay its cost forever?)</li>

<li>But functions and methods that do, in fact,

need to use the regular expression

will no longer incur a repeated cost for its compilation.

The compiled regular expression

is ready to start scanning a string immediately!

If the regular expression is used frequently,

like in the inner loop of a costly operation like parsing,

the savings can be considerable.</li>

<li>The global name will make calling code more readable

than if the regular expression, when used locally,

is used anonymously in a larger expression.

(If readability is the only concern, though,

remember that you can define the regular expression’s string as a global

but skip the cost of compiling it at module level.)</li>

</ul>

This list of tradeoffs is about the same, by the way,

if you move a regular expression out into a class attribute

instead of moving it all the way out to the global scope.

When I finally get around to writing about Python and classes,

I’ll link from here to further thoughts on class attributes.

</div>

<h2>Global Objects that are mutable<a class="headerlink" href="#global-objects-that-are-mutable" title="Permalink to this headline">¶</a></h2>

But what about Global Objects that are mutable?

They are easiest to justify when they wrap system resources

that are by their nature also global to an operating system process.

One example in the Standard Library itself is the <code class="docutils literal notranslate">environ</code>

<a class="reference external" href="https://docs.python.org/3/library/os.html#os.environ">object</a>

that gives your Python program the “environment” —

the text keys and values supplying your timezone, terminal type, so forth —

that was passed to your Python program from its parent process.

Now,

it is arguable whether your program

should really be writing new values into its environment as it runs.

If you’re launching a subprocess

that needs an environment variable adjusted,

the <code class="docutils literal notranslate">subprocess</code> routines offer an <code class="docutils literal notranslate">env</code> parameter.

But if code does need to manipulate this global resource,

then it makes sense for that access to be mediated

by a correspondingly global Python object:

<div class="highlight-default notranslate"><div class="highlight"><pre># os.py

environ = _createenviron()

</pre></div>

</div>

Through this global object,

the various routines, and perhaps threads, in a Python program

coordinate their access to this process-wide resource.

Any change:

<div class="highlight-python notranslate"><div class="highlight"><pre>import os

os.environ['TERM'] = 'xterm'

</pre></div>

</div>

— will be immediately visible to any other part of the program

that reads that environment key:

<div class="highlight-default notranslate"><div class="highlight"><pre>>>> os.environ['TERM']

'xterm'

</pre></div>

</div>

The problems with coupling distant parts of your codebase,

and even unrelated parts of different libraries,

through a unique global object are well known.

<li>Tests that were previously independent

are suddenly coupled through the global object

and can no longer safely be run in parallel.

If one test makes a temporary assignment to <code class="docutils literal notranslate">environ['PATH']</code>

just before another test launches a binary with <code class="docutils literal notranslate">subprocess</code>,

the binary will inherit the test value of <code class="docutils literal notranslate">$PATH</code> —

possibly causing an error.</li>

<li>You can sometimes serialize access to a global object through a lock.

But unless you do a thorough audit

of all of the libraries your code uses,

and continue to audit them when upgrading to new versions,

it can be difficult to even know which tests call code

that ultimately touches particular global object like <code class="docutils literal notranslate">environ</code>.</li>

<li>Even tests run serially, not in parallel, will now wind up coupled

if one test fails to restore <code class="docutils literal notranslate">environ</code> to its original state

before the next test runs.

This can, it’s true, be mitigated with teardown routines

or with mocks that automatically restore state.

But unless every single test is perfectly cautious,

your test suite can still suffer from exceptions

that depend on random test ordering

or on whether a previous test succeeded or exited early.</li>

<li>These dangers beset not only tests but production runs as well.

Even if your application doesn’t launch multiple threads,

there can be surprising cases

where a refactoring winds up calling code

that performs one operation on <code class="docutils literal notranslate">environ</code>

right in the middle of another routine

that was also in the middle of transforming its state.</li>

</ul>

The Standard Library has more examples of the Mutable Global pattern —

both public globals and private ones litter its modules.

Some correspond to unique resources at the system level:

<div class="highlight-default notranslate"><div class="highlight"><pre># Lib/multiprocessing/process.py

_current_process = _MainProcess()

_process_counter = itertools.count(1)

</pre></div>

</div>

Others correspond to no outside resource

but instead serve as single points of coordination

for a process-wide activity like logging:

<div class="highlight-default notranslate"><div class="highlight"><pre># Lib/logging/__init__.py

root = RootLogger(WARNING)

</pre></div>

</div>

Third-party libraries can supply dozens of more examples,

from global HTTP thread pools and database connections

to registries of request handlers, library plugins, and third-party codecs.

But in every case,

the Mutable Global courts all of the dangers listed above

in return for the convenience

of putting a resource where every module can reach it.

My advice, to the extent that you can,

is to write code that accepts arguments

and returns values computed from them.

Failing that, try passing database connections or open sockets

to code that will need to interact with the outside world.

It is a compromise

for code that finds itself stranded from the resources it needs

to resort to accessing a global.

The glory of Python, of course,

is that it usually makes even anti-patterns and compromises

read fairly elegantly in code.

An assignment statement at the global level of a module

is as easy to write and read as any other assignment statement,

and callers can access the Mutable Global

through exactly the same import statement

they use for functions and classes.

</div>

<h2>Import-time I/O<a class="headerlink" href="#import-time-i-o" title="Permalink to this headline">¶</a></h2>

Many of the worst Global Objects are those

that perform file or network I/O at import time.

They not only impose the cost of that I/O

on every library, script, and test that need the module,

but expose them to failure if a file or network is not available.

Library authors have an unfortunate tendency to make assumptions like

“the file <code class="docutils literal notranslate">/etc/hosts</code> will always exist”

when, in fact, they can’t know ahead of time

all the exotic environments their code will one day face —

maybe a tiny embedded system that in fact lacks that file;

maybe a continuous integration environment

spinning up containers that lack any network configuration at all.

Even when faced with this possibility,

a module author might still try to defend their import-time I/O:

“But delaying the I/O until after import time

simply postpones the inevitable —

if the system doesn’t have <code class="docutils literal notranslate">/etc/hosts</code>

then the user will get exactly the same exception later anyway.”

The attempt to make this excuse reveals three misunderstandings:

<li>Errors at import time are far more serious than errors at runtime.

Remember that at the moment your package is imported,

the program’s main routine has probably not started running —

the caller is usually still up in the middle

of the stack of <code class="docutils literal notranslate">import</code> statements at the top of their file.

They have probably not yet set up logging

and have not yet entered their application’s main <code class="docutils literal notranslate">try…except</code>

block that catches and reports failures,

so any errors during import

will probably print directly to the standard output

instead of getting properly reported.</li>

<li>Applications are often written

to survive the failure of some operations

so that in an emergency they can still perform other functions.

Even if features that need your library will now hit an exception,

the application might have many others it can continue to offer —

or could,

if you didn’t kill it with an exception at import time.</li>

<li>Finally, library authors need to keep in mind

that a Python program that imports their library

might not even use it!

Never assume that simply because your code has been imported,

it will be used.

There are many situations where a module gets imported incidentally,

as the dependency of yet further modules,

but never happens to get called.

By performing I/O at import time,

you could impose expense and risk on hundreds of programs and tests

that don’t even need or care about your network port,

connection pool, or open file.</li>

</ol>

For all of these reasons,

it’s best for your global objects

to wait until they’re first called

before opening files and creating sockets —

because it’s at the moment of that first call

that the library knows the main program is now up and running,

and knows that its services are in fact definitely needed

in this particular run of the program.

I’ll admit that,

when my package needs to load a small data file

that’s embedded in the package itself,

I do sometimes break this rule.

</div>

</article>

<hr>

</body>

</html>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

FilesExpand file tree

index.html

Latest commit

History

index.html

File metadata and controls