semvec/pypi-packages huggingface dataset:
compile 1.0.3
Compiling Python source code into bytecode in production environment

## Compile
> Compiling Python source code into bytecode in production environment

## How To Use
```shell script
python -m compile -h  # help
python -m compile . -b -f  # Compile current directory
```

## 编译
> 将 python 源代码编译成供生产环境使用的机器字节码

## 如何使用
```shell script
python -m compile -h  # 帮助
python -m compile . -b -f  # 编译当前目录
```
membrane 0.0.4
A Flask and Flask-RESTful argument parser.
Requires Python: >=3.6

# membrane.py ��
A [Flask](https://palletsprojects.com/p/flask/) arg-parser &amp; splitter to ensure wanted data gets through, unwanted data stays out, and required data shows up.

Compatible with [Flask-RESTful](https://flask-restful.readthedocs.io/en/latest/). ��

## Basic Usage ��

```python
from flask import Flask
app = Flask(__name__)


@app.route('/')
def route_handler():
    return "No args~!"
```

Above we see a basic `Flask` application with a root API handler. No query options are yet passed to our root.

Let's say we wanted to handle the query parameter `?limit=0` in the request handler. We can use membrane to do this.

```python
from flask import Flask, jsonify
from membrane import membrane
app = Flask(__name__)


@app.route('/')
@membrane({'limit': int})
def route_handler(microbe):
	'''Here microbe should be either an empty dict: {} or dict: {"limit": ?}'''

    return jsonify(microbe)
```

## Defining Membranes ��

The *membrane*, a wrapper function, can take multiple layers of type *dict* which will act as a filter for the: 1) query parameters; 2) body; and 3) headers passed to the request handler. The route_handler will take these filtered dicts as `*args`.

The basic structure is as follows:

```python
simple_membrane = {"limit": int}
complex_membrane = {
	"other_parameter": {
		"type": lambda x: int(x),
		"options": (1, 2, 3,),
		"default": 1,
		"required": False,
		"location": "params"
	}
}
```

In the simple_membrane, we want to take limit from either the params, body, or headers and convert it to an int (or verify that it is of type int). We're also allowed to use custom functions to handle conversions here.

The complex_membrane is different in that it's a dict with additional options.

 - `type`: any callable function or class.
 - `options`: a tuple of accepted values.
 - `default`: if not provided, use this as a default. If you need this value to be generated at the time of parsing, provide a callable function that returns the proper value.
 - `required`: should the server throw an error if this value is not provided?
 - `location`: where in the request should we search for this value: ("params", "body", "headers", "files").

To use multiple layers for a route handler, simply list them out.

```python
@app.route('/')
@membrane(simple_membrane, complex_membrane)
def route_handler(simple_microbe, complex_microbe):
    return jsonify([simple_microbe, complex_microbe])
```

## Error Handling ⚠️

Exported from membrane are exceptions: `RequiredFieldError`, `NotAnOptionError`, `TypeConversionError`.

You can handle these errors yourself or use our default error handler.

```python
from membrane import error_handler

app = Flask(__name__)
error_handler(app)
```

Otherwise you can handle these errors however you like.
ezception 0.0.2
Simple exceptions and messaging
Requires Python: >=3.6

# EZCeption (and EZMessage)

These classes provide a simplified means to define exception classes and
message attributes.

# Goals

* Less boilerplate to define error classes so they'll be used more.
* Formatting does not happen at raise time so catching errors doesn't incur
  string computation cost.
* Exception fields are easier to probe by exception handlers.
* Class-bases exceptions are a snap to define.
* Works with regular Python exception classes.
* Interfaces with the gettext module by default.
* Allows for associating other i18n messaging in the error classes.

# Installation.

```bash
pip install ezception
```

**NOTE: ezception is not on pypi yet.  Until official releases are available:**

```bash
pip install https://github.com/hrharkins/ezception/archive/master.zip
```

# Usage

```python
import ezception

class MyWebRequester(object):

    class Error(ezception.EZCeption):
        'A general error has occurred.'

    class OpenError(Error):
        'An error opening {self.url!r} has occurred.'

    class NoURLError(OpenError):
        '''
        No URL was provided.
        ''''

    class NoURLError(OpenError):
        '''
        The scheme {self.scheme!r} is not acceptable.
        '''

    ...

    def open(self, url):
        ... stuff happens.

        ... Oh noes!
        raise self.BadSchemeError(scheme=url.scheme)

```

So in the example the class defines a simple hierarchy of errors.  Progreammers 
can trivially trap MyWebRequester.Error to catch anything generated by 
MyWebRequester.  Because it's very simple to define those errors, a more 
robust exception hierarchy is more likely to emerge.

In addition, the message is NOT generated at exception time.  Because of this,
it is easy to catch and determine better handling code.  The default Python
exceptions use args, which requires the programmer to have tighter coupling 
with the error classes to acquire the parameters of the failure (or the
error class needs to define more properties).

Only when the exception is printed does stringification occur.  In addition,
the message to be presented is processed using the gettext module, so adding
support for other languages for such messages is possible using regular .po
files.  All messages are tracked by a global ezception.ALL_MSGS dict so
generating base .po files is also simplified.