Fix some trivial typos in comments and classifiers template

Author: xni

warehouse/admin/templates/admin/classifiers/index.html

@@ -31,7 +31,7 @@ <h3 class="box-title">Add New Top-Level Classifier</h3>
     <div class="box-body">
       <div class="form-group col-sm-4">
         <label for="parent">Classifier:</label>
-        <input name="parent" data-action="input->parent-classifier#update" data-target="parent-classifier.input" class="form-control" autocomplete="off" autocorrect="off" autocapitalize="off">
+        <input name="parent" id="parent" data-action="input->parent-classifier#update" data-target="parent-classifier.input" class="form-control" autocomplete="off" autocorrect="off" autocapitalize="off">
       </div>
     </div>
     <div class="box-footer">
@@ -53,7 +53,7 @@ <h3 class="box-title">Add Sub-Classifier</h3>
     <div class="box-body">
       <div class="form-group col-sm-4">
         <label for="parent_id">Parent:</label>
-        <select name="parent_id" data-target="child-classifier.parent" data-action="child-classifier#update">
+        <select name="parent_id" id="parent_id" data-target="child-classifier.parent" data-action="child-classifier#update">
           <option disabled selected>Select one</option>
           {% for classifier in classifiers %}
           {% if classifier.l5 == 0 %}
@@ -86,8 +86,8 @@ <h3 class="box-title">Deprecate Classifier</h3>
     <input name="csrf_token" type="hidden" value="{{ request.session.get_csrf_token() }}">
     <div class="box-body">
       <div class="form-group col-sm-4">
-        <label for="parent_id">Classifier:</label>
-        <select name="classifier_id">
+        <label for="classifier_id">Classifier:</label>
+        <select name="classifier_id" id="classifier_id">
           <option disabled selected>Select one</option>
           {% for classifier in classifiers %}
           <option value="{{ classifier.id }}" {{'disabled' if classifier.deprecated else ''}}>

warehouse/db.py

@@ -40,22 +40,22 @@
 DEFAULT_ISOLATION = "READ COMMITTED"
 
 
-# On the surface this might seem wrong, becasue retrying a request whose data violates
+# On the surface this might seem wrong, because retrying a request whose data violates
 # the constraints of the database doesn't seem like a useful endeavor. However what
 # happens if you have two requests that are trying to insert a row, and that row
 # contains a unique, user provided value, you can get into a race condition where both
 # requests check the database, see nothing with that value exists, then both attempt to
 # insert it. One of the requests will succeed, the other will fail with an
 # IntegrityError. Retrying the request that failed will then have it see the object
-# created by the other request, and will have it do the appropiate action in that case.
+# created by the other request, and will have it do the appropriate action in that case.
 #
 # The most common way to run into this, is when submitting a form in the browser, if the
 # user clicks twice in rapid succession, the browser will send two almost identical
 # requests at basically the same time.
 #
 # One possible issue that this raises, is that it will slow down "legitimate"
 # IntegrityError because they'll have to fail multiple times before they ultimately
-# fail. We consider this an acceptable trade off, because determinsitic IntegrityError
+# fail. We consider this an acceptable trade off, because deterministic IntegrityError
 # should be caught with proper validation prior to submitting records to the database
 # anyways.
 pyramid_retry.mark_error_retryable(IntegrityError)