44 karma · joined July 2, 2012
Given this, I tend to prefer a single, formatting-only commit when introducing formatting standards to an existing codebase. Otherwise, it’s difficult to take advantage of QOL features like auto formatting in your editor, or other formatting tools which tend to operate on entire files. Then PRs end up being mixed with formatting changes, which adds friction to the review process.
> Rather than build the commits that have been pushed to the branch the pull request is from, we build the merge between the source branch and the upstream branch.
https://docs.travis-ci.com/user/pull-requests/#how-pull-requ...
Good news on that front at least. PEP-895 [1] removes the need for `T = TypeVar(...)` boilerplate in Python 3.12.
- https://docs.djangoproject.com/en/4.1/ref/settings/#debug
Setting DEBUG = False doesn't cause in Internal Server Issue. The issue is caused by something else, having DEBUG = True just means Django will return a detailed error page, instead of a generic 500 error page.
IIRC, DEBUG = True also used to leak memory, which doesn't matter so much for local development, where it's intended to be used.
> Any identifier of the form __spam (at least two leading underscores, at most one trailing underscore) is textually replaced with _classname__spam, where classname is the current class name with leading underscore(s) stripped.
See https://docs.python.org/3/tutorial/classes.html#private-vari...
Obviously your choice depends greatly on budget + availability of hardware, as well as your desired resolution, but I'd suggest the 2070 or 2080 (maybe 2080ti?) as a good starting point.
The housing market is probably a good example. Many participants probably only purchase property once or twice in their lives (less even if you consider the case of a married couple buying a house, that's 0.5 purchases per person).
The CDC ran such a study. IDK about results, or how many people participated.
Sure, by default Django may create a single settings.py, but common practice is to split that into a settings package, containing a base settings module for common settings, and other files for different scenarios, say "development" and "production". Either / all of them can load secrets etc. from the environment, so the "production" settings file is probably better thought of as "deployment" settings, when supporting multiple deployed environments e.g. staging and production.
Pymetrics | Senior Cloud Infrastructure Engineer | New York, NY | https://pymetrics.workable.com/j/18CE7639C1
Pymetrics | Senior Full Stack Engineer | New York, NY | https://pymetrics.workable.com/j/9711230D9A
Pymetrics | Data Engineer | New York, NY | https://pymetrics.workable.com/j/D52FBD6B6D
Other positions available, in London and Singapore as well as NYC: https://www.pymetrics.com/our-careers/
Using neuroscience-based assessments and machine learning algorithms, pymetrics (www.pymetrics.com) is reinventing the recruiting industry by matching candidates to jobs and companies where they are most likely to succeed. We are leading the charge in an evolving industry, and growing our amazing team to support the mission of using data to unleash one's full potential.
In [21]: @enum.unique
...: class Animal(enum.Enum):
...: DOG = 1
...: CAT = 2
...: PIG = 2
...:
---------------------------------------------------------------------------
ValueError Traceback (most recent call last)
<ipython-input-21-cbc1625bb41c> in <module>
1 @enum.unique
----> 2 class Animal(enum.Enum):
3 DOG = 1
4 CAT = 2
5 PIG = 2
~/.virtualenvs/py3/lib/python3.6/enum.py in unique(enumeration)
834 ["%s -> %s" % (alias, name) for (alias, name) in duplicates])
835 raise ValueError('duplicate values found in %r: %s' %
--> 836 (enumeration, alias_details))
837 return enumeration
838
ValueError: duplicate values found in <enum 'Animal'>: PIG -> CAT
It's intended to catch programmer errors - not really useful for small enums like this one, but in a large enum, having duplicates could be difficult to notice, and might cause some insidious bugs.