semvec/pypi-packages huggingface dataset:
typescore 0.11
typescore - generate typing completeness scores (and more) for a set of packages

# typescore

__`typescore`__ generates typing completeness scores (and more) for a set of packages.

Usage:

```sh
  typescore [--packages <packages>] [--scores <scorefile>] [--sep <sep>] [--verbose] [<package>...]
  typescore --help
  typescore --version

Options:
  --packages <packages> File containing the list of packages.
  --scores <scorefile>  The output file (if not stdout).
  --sep <sep>           CSV column separator. [default: ,]
  -v, --verbose         Include package info in the output.
  -h, --help            Show this help.
  -V, --version         Show the version.
```

`typescore` uses pyright to score the typing completeness of a set of Python
packages. It reads this list from `<packages>` and writes the results to
`<scorefile>`. If errors prevent it from scoring a package it will set the
score to 0%.

The output has the form:

    package,typed,module,score,extra_columns

or, if `--verbose` is specified:

    package,version,typed,module,score,stub_package,package_description,extra_columns

`typed` is a Boolean and tells whether the package had a `py.typed` file.

Note: we only score top-level modules, not submodules. The assumption is
that scores for top-level modules would be reasonably representative of
the packages all-up.

`<packages>` should have one package name per line. It can be a CSV file with
the package name as the first column, in which case other columns will be
included in the score file output (the `extra_columns`). A typical extra column
might be the package rank on PyPI downloads.

While it would be useful to be able to measure the coverage scores on stub packages too, pyright does not support doing so. As a result, you should evaluate whether a stub package is better than the inline types for a package yourself beffore making use of it.


See [latest-scores.md](https://github.com/gramster/typescore/blob/main/latest-scores.md) for results in markdown form.
automx3 2022.3
Mail client autoconfiguration service
Requires Python: >=3.7

# automx3: Email client configuration made easy

automx3 makes configuring email accounts easy. It unites methods for automated mailbox configuration from Apple's
[Mobileconfig](https://support.apple.com/de-de/guide/profile-manager/pmdbd71ebc9/mac), Microsoft's
[Autodiscover](https://docs.microsoft.com/de-de/exchange/architecture/client-access/autodiscover?view=exchserver-2019)
and Mozilla's [Autoconfig](https://developer.mozilla.org/de/docs/Mozilla/Thunderbird/Autokonfiguration) in one tool.
automx3 is successor to automx. It has been designed to be easier to setup, easier to configure and easier to use.

## Copyright
automx2 is Copyright © 2022 Gaspard d'Hautefeuille.
The fork automx3 is Copyright © 2022 Gaspard d'Hautefeuille.
automx3 is licensed under the GNU General Public License V3 or later. The project is hosted on GitHub in the
[HLFH/automx3](https://github.com/HLFH/automx3) repository and published on
[PyPI.org](https://pypi.org/project/automx3/).

## Documentation

Detailed documentation is available in [HTML](https://hlfh.github.io/automx3/),
[PDF](https://github.com/hlfh/automx3/blob/master/docs/automx3.pdf) and
[other formats](https://github.com/hlfh/automx3/blob/master/docs).

## Contributing

This project currently accepts code contributions as long as they don't infringe copyrights from others.

Furthermore, submitting ideas, suggestions and bug reports in the form of
[GitHub issues](https://github.com/hlfh/automx3/issues) is welcome. Please refer to
[this blog article](https://about.gitlab.com/blog/2016/03/03/start-with-an-issue/) for an explanation on why issues
are a good method to share and discuss ideas.

## Sponsorship

It is possible to sponsor specific new features. Please contact me via email or @rseichter to discuss this in detail.
friendly-idle 0.4
Customized version of IDLE for friendly/friendly-traceback.
Requires Python: >=3.8.10

# friendly_idle

This provides a "live patched" [1] version of IDLE to include friendly/friendly-traceback.

Install using the usual `pip install friendly_idle`.

Requires either Python 3.8.10+, or Python >= 3.9.5.  (It has not been tested with Python 3.11.)

You can launch it from a terminal using `friendly_idle`.

![image](https://user-images.githubusercontent.com/629698/174356637-2bf86ecd-a817-4189-89eb-3939c4122dd9.png)

That's it. From there on, if your code triggers a traceback, you will be able to get
interactive help from the embedded version of friendly/friendly-traceback.

![image](https://user-images.githubusercontent.com/629698/174356738-58d3af3f-a8ac-469a-b98e-16648961916b.png)


Please see https://friendly-traceback.github.io/docs/index.html for information about friendly/friendly-traceback.

---

[1] By "live patched", I mean that it uses regular IDLE but patches a few modules as they are imported.
LegendsLIB 4.0
For developers
Keywords: LegendsLIB


<h1 align="center">LegendsLIB</h1>
<p align="center">It's a Usefull Project for Developers ... It checkers Emails Found Or Not Found</p>

<p align="center"> • DevVlopered The Lib BY ALAA7C • </p>


## Installing :
```
pip install LegendsLIB

```
```
INFO:  https://t.me/LegendsLIB
```
cuco 0.9.0
Project for making it easier to write configuration files which may be automatically converted into a set of alternative system setups

<p align="center">
    <img src="assets/logo.png"/>
</p>

# CuCo

CuCo (**Cu**te **Co**nfiguration) is a project for making it easier to write configuration files which may be automatically converted into a set of alternative system setups.

## Installation

To install the package, execute the following command:

```sh
pip install cuco
```

## Usage

To use the package, first, annotate some of your classes with annotator `config_parser` according to the following example:

```py
from dataclasses import dataclass
from cuco import config_parser, Config

@config_parser()
@dataclass
class Foo(Config):
    bar: int = 0
    baz: str = None

    name: str = None  # This field contains configuration name, which includes values for alternating configuration fields in a particular setup
```

Then you would need to create a file with name `assets/types/foo.yml` for this class with specification of keys which are allowed to set up in this file (the following example demonstrates that field `qux` from configuration file will be translated into the field `bar` of the generated objects):

```yaml
qux: bar
```

After that you finally can create a file with name `assets/foo/default.yml` with some value for the configurable fields (the given example demonstrates array consisting of 2 values, which will lead to generation of 2 config objects):

```yaml
_type: foo

qux:
    - 1
    - 2
```

The last step is calling method `make_configs` which will read all the configuration files and decide how they should be parsed, returning the list of generated configuration objects:

```py
from .Foo import Foo

configs = make_configs(
    path = 'assets/foo/default.yml', type_specification_root = 'assets/types'
)
```

## Testing

To run the tests, execute the following command:

```sh
python -m unittest discover test
```