#magicmock — Public Fediverse posts

You can try this in a terminal:
```
python -c "from unittest.mock import MagicMock; open(MagicMock(), 'w'); print(0)"
```

#Python #MagicMock #footgun

But why didn't the tests fail under pytest?

pytest wraps, substitutes or otherwise messes with `sys.stdout` enough that fd 1 being dead doesn't cause prints to fail.

The best part? The method that calls `shutil.copy` is called `_safe_copy`, but it doesn't check whether the values it receives are strings or `Path`s. So it happily passes a `MagicMock` along as the copy destination.

So yeah, test your tests, and if you call something safe make it at least careful.

#Python #MagicMock #footgun

Tests started failing when run with unittest, had been running fine with pytest for a while.

Tests error out with `OSError: [Errno 9] Bad file descriptor`.

Turns out if you `shutil.copy` something onto a `MagicMock`, you kill `sys.stdout`:

```
from unittest.mock import MagicMock
import shutil

m = MagicMock()
m.__fspath__.__index__() # → 1

shutil.copy(filename, m)
[errors omitted]

print(1) # → OSError: [Errno 9] Bad file descriptor
```

Much head scratching!

#Python #MagicMock #footgun

@astraluma

It depends on what, exactly, you want. time.localtime() will give you a value in the system's configured #timezone. time.gmtime() will give you #UTC. The difference between those will tell you the current local time's offset from UTC.

If you want the name of the configured timezone, on many Unix-type systems, you can read /etc/timezone to get it.

If you want more specific info about a timezone, you can add an external dependency which includes (or provides access to a system-provided) database of timezone info. This stuff changes often, and is decided politically rather than technically, so it's a moving target and the #Python #stdlib doesn't try to include it. `pytz` is one such package with a fairly complete database.

And you can easily override any of these in a test framework. Using unittest.mock.MagicMock(), for example, lets you override any of the above with whatever value you want those functions to return.

#pytz #test #mock #MagicMock

@astraluma

It depends on what, exactly, you want. time.localtime() will give you a value in the system's configured #timezone. time.gmtime() will give you #UTC. The difference between those will tell you the current local time's offset from UTC.

If you want the name of the configured timezone, on many Unix-type systems, you can read /etc/timezone to get it.

If you want more specific info about a timezone, you can add an external dependency which includes (or provides access to a system-provided) database of timezone info. This stuff changes often, and is decided politically rather than technically, so it's a moving target and the #Python #stdlib doesn't try to include it. `pytz` is one such package with a fairly complete database.

And you can easily override any of these in a test framework. Using unittest.mock.MagicMock(), for example, lets you override any of the above with whatever value you want those functions to return.

#pytz #test #mock #MagicMock

@astraluma

It depends on what, exactly, you want. time.localtime() will give you a value in the system's configured #timezone. time.gmtime() will give you #UTC. The difference between those will tell you the current local time's offset from UTC.

If you want the name of the configured timezone, on many Unix-type systems, you can read /etc/timezone to get it.

If you want more specific info about a timezone, you can add an external dependency which includes (or provides access to a system-provided) database of timezone info. This stuff changes often, and is decided politically rather than technically, so it's a moving target and the #Python #stdlib doesn't try to include it. `pytz` is one such package with a fairly complete database.

And you can easily override any of these in a test framework. Using unittest.mock.MagicMock(), for example, lets you override any of the above with whatever value you want those functions to return.

#pytz #test #mock #MagicMock

@astraluma

It depends on what, exactly, you want. time.localtime() will give you a value in the system's configured #timezone. time.gmtime() will give you #UTC. The difference between those will tell you the current local time's offset from UTC.

If you want the name of the configured timezone, on many Unix-type systems, you can read /etc/timezone to get it.

If you want more specific info about a timezone, you can add an external dependency which includes (or provides access to a system-provided) database of timezone info. This stuff changes often, and is decided politically rather than technically, so it's a moving target and the #Python #stdlib doesn't try to include it. `pytz` is one such package with a fairly complete database.

And you can easily override any of these in a test framework. Using unittest.mock.MagicMock(), for example, lets you override any of the above with whatever value you want those functions to return.

#pytz #test #mock #MagicMock

@astraluma

It depends on what, exactly, you want. time.localtime() will give you a value in the system's configured #timezone. time.gmtime() will give you #UTC. The difference between those will tell you the current local time's offset from UTC.

If you want the name of the configured timezone, on many Unix-type systems, you can read /etc/timezone to get it.

If you want more specific info about a timezone, you can add an external dependency which includes (or provides access to a system-provided) database of timezone info. This stuff changes often, and is decided politically rather than technically, so it's a moving target and the #Python #stdlib doesn't try to include it. `pytz` is one such package with a fairly complete database.

And you can easily override any of these in a test framework. Using unittest.mock.MagicMock(), for example, lets you override any of the above with whatever value you want those functions to return.

#pytz #test #mock #MagicMock