first commit

frozen_application_license.txt

@@ -0,0 +1,63 @@
+## Why this file is included
+
+This program has been frozen with cx_Freeze.  The freezing process
+resulted in certain components from the cx_Freeze software being included
+in the frozen application, in particular bootstrap code for launching
+the frozen python script.  The cx_Freeze software is subject to the
+license set out below.
+
+# Licensing
+
+-   Copyright © 2020-2025, Marcelo Duarte.
+-   Copyright © 2007-2019, Anthony Tuininga.
+-   Copyright © 2001-2006, Computronix (Canada) Ltd., Edmonton, Alberta,
+    Canada.
+-   All rights reserved.
+
+NOTE: This license is derived from the Python Software Foundation
+License which can be found at
+<https://docs.python.org/3/license.html#psf-license-agreement-for-python-release>
+
+## License for cx_Freeze
+
+1.  This LICENSE AGREEMENT is between the copyright holders and the
+    Individual or Organization ("Licensee") accessing and otherwise
+    using cx_Freeze software in source or binary form and its associated
+    documentation.
+2.  Subject to the terms and conditions of this License Agreement, the
+    copyright holders hereby grant Licensee a nonexclusive,
+    royalty-free, world-wide license to reproduce, analyze, test,
+    perform and/or display publicly, prepare derivative works,
+    distribute, and otherwise use cx_Freeze alone or in any derivative
+    version, provided, however, that this License Agreement and this
+    notice of copyright are retained in cx_Freeze alone or in any
+    derivative version prepared by Licensee.
+3.  In the event Licensee prepares a derivative work that is based on or
+    incorporates cx_Freeze or any part thereof, and wants to make the
+    derivative work available to others as provided herein, then
+    Licensee hereby agrees to include in any such work a brief summary
+    of the changes made to cx_Freeze.
+4.  The copyright holders are making cx_Freeze available to Licensee on
+    an "AS IS" basis. THE COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR
+    WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT
+    LIMITATION, THE COPYRIGHT HOLDERS MAKE NO AND DISCLAIM ANY
+    REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY
+    PARTICULAR PURPOSE OR THAT THE USE OF CX_FREEZE WILL NOT INFRINGE
+    ANY THIRD PARTY RIGHTS.
+5.  THE COPYRIGHT HOLDERS SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER
+    USERS OF CX_FREEZE FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL
+    DAMAGES OR LOSS AS A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE
+    USING CX_FREEZE, OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE
+    POSSIBILITY THEREOF.
+6.  This License Agreement will automatically terminate upon a material
+    breach of its terms and conditions.
+7.  Nothing in this License Agreement shall be deemed to create any
+    relationship of agency, partnership, or joint venture between the
+    copyright holders and Licensee. This License Agreement does not
+    grant permission to use copyright holder's trademarks or trade name
+    in a trademark sense to endorse or promote products or services of
+    Licensee, or any third party.
+8.  By copying, installing or otherwise using cx_Freeze, Licensee agrees
+    to be bound by the terms and conditions of this License Agreement.
+
+Computronix® is a registered trademark of Computronix (Canada) Ltd.

gitFocePushRemote.bat

@@ -0,0 +1,7 @@
+@echo off  
+setlocal  
+  
+:: 假设你已经处于正确的Git仓库目录中  
+  
+:: 添加所有更改到暂存区  
+git push -f --set-upstream origin master:master

gitInit.bat

@@ -0,0 +1,34 @@
+@echo off  
+setlocal enabledelayedexpansion  
+  
+:: 获取当前目录的完整路径  
+set "current_dir=%CD%"  
+  
+:: 提取当前目录的最后一个文件夹名称（不包括路径）  
+for %%i in ("%current_dir%") do set "folder_name=%%~nxi"  
+  
+:: 去除路径中的最后一个反斜杠和文件名后的点（如果有的话，比如C:\folder.）  
+:strip_trailing_slash_and_dot  
+if "!folder_name:~-1!"=="\" (  
+    set "folder_name=!folder_name:~0,-1!"  
+    goto :strip_trailing_slash_and_dot  
+)  
+if "!folder_name:~-1!"=="." (  
+    set "folder_name=!folder_name:~0,-1!"  
+    goto :strip_trailing_slash_and_dot  
+)  
+  
+:: 构建你的git命令  
+set "git_command=git remote add origin http://git.cloudpeaks.cn/droplin/%folder_name%.git"  
+  
+:: 输出或执行你的git命令  
+echo !git_command!  
+:: 如果你要实际执行这个命令，取消下面的rem注释  
+:: !git_command!  
+  
+git init
+
+!git_command!
+
+endlocal
+pause

gitPushRemote.bat

@@ -0,0 +1,41 @@
+@echo off  
+setlocal  
+  
+:: 假设你已经处于正确的Git仓库目录中  
+  
+:: 添加所有更改到暂存区  
+git add .
+
+echo Execute command: git add
+:: 等待用户输入提交信息  
+set /p COMMIT_MESSAGE="Please enter the submission update information(default commit :first commit if no input):"  
+
+echo 用户输入的提交信息为: %COMMIT_MESSAGE% 
+set commitValue="first commit" 
+:: 如果变量为空，则设置默认值为“第一次提交”  
+if defined COMMIT_MESSAGE (  
+    set commitValue=%COMMIT_MESSAGE%
+)  
+echo 用户输入的提交信息为: %commitValue% 
+:: 执行git commit命令，使用用户输入的提交信息  
+git commit -m %commitValue%
+
+:: 检查上一个命令是否成功（即提交是否成功）  
+if %errorlevel% neq 0 (  
+    echo Git commit failed!  
+    @REM exit /b %errorlevel%  
+) else ( 
+    echo Git commit successful!  
+)
+:: 执行git push命令（假设你已经在本地master分支上并且想要推送到origin的master分支）  
+git push -u origin master  
+
+:: 检查上一个命令是否成功（即推送是否成功）  
+if %errorlevel% neq 0 (  
+    echo Git push failed!  
+    @REM exit /b %errorlevel%  
+) else (  
+    echo Git push successful!  
+)
+endlocal
+pause

lib/ctypes/macholib/README.ctypes

@@ -0,0 +1,7 @@
+Files in this directory come from Bob Ippolito's py2app.
+
+License: Any components of the py2app suite may be distributed under
+the MIT or PSF open source licenses.
+
+This is version 1.0, SVN revision 789, from 2006/01/25.
+The main repository is http://svn.red-bean.com/bob/macholib/trunk/macholib/

lib/ctypes/macholib/fetch_macholib

@@ -0,0 +1,2 @@
+#!/bin/sh
+svn export --force http://svn.red-bean.com/bob/macholib/trunk/macholib/ .

lib/ctypes/macholib/fetch_macholib.bat

@@ -0,0 +1 @@
+svn export --force http://svn.red-bean.com/bob/macholib/trunk/macholib/ .

lib/email/architecture.rst

@@ -0,0 +1,216 @@
+:mod:`email` Package Architecture
+=================================
+
+Overview
+--------
+
+The email package consists of three major components:
+
+    Model
+        An object structure that represents an email message, and provides an
+        API for creating, querying, and modifying a message.
+
+    Parser
+        Takes a sequence of characters or bytes and produces a model of the
+        email message represented by those characters or bytes.
+
+    Generator
+        Takes a model and turns it into a sequence of characters or bytes.  The
+        sequence can either be intended for human consumption (a printable
+        unicode string) or bytes suitable for transmission over the wire.  In
+        the latter case all data is properly encoded using the content transfer
+        encodings specified by the relevant RFCs.
+
+Conceptually the package is organized around the model.  The model provides both
+"external" APIs intended for use by application programs using the library,
+and "internal" APIs intended for use by the Parser and Generator components.
+This division is intentionally a bit fuzzy; the API described by this
+documentation is all a public, stable API.  This allows for an application
+with special needs to implement its own parser and/or generator.
+
+In addition to the three major functional components, there is a third key
+component to the architecture:
+
+    Policy
+        An object that specifies various behavioral settings and carries
+        implementations of various behavior-controlling methods.
+
+The Policy framework provides a simple and convenient way to control the
+behavior of the library, making it possible for the library to be used in a
+very flexible fashion while leveraging the common code required to parse,
+represent, and generate message-like objects.  For example, in addition to the
+default :rfc:`5322` email message policy, we also have a policy that manages
+HTTP headers in a fashion compliant with :rfc:`2616`.  Individual policy
+controls, such as the maximum line length produced by the generator, can also
+be controlled individually to meet specialized application requirements.
+
+
+The Model
+---------
+
+The message model is implemented by the :class:`~email.message.Message` class.
+The model divides a message into the two fundamental parts discussed by the
+RFC: the header section and the body.  The `Message` object acts as a
+pseudo-dictionary of named headers.  Its dictionary interface provides
+convenient access to individual headers by name.  However, all headers are kept
+internally in an ordered list, so that the information about the order of the
+headers in the original message is preserved.
+
+The `Message` object also has a `payload` that holds the body.  A `payload` can
+be one of two things: data, or a list of `Message` objects.  The latter is used
+to represent a multipart MIME message.  Lists can be nested arbitrarily deeply
+in order to represent the message, with all terminal leaves having non-list
+data payloads.
+
+
+Message Lifecycle
+-----------------
+
+The general lifecycle of a message is:
+
+    Creation
+        A `Message` object can be created by a Parser, or it can be
+        instantiated as an empty message by an application.
+
+    Manipulation
+        The application may examine one or more headers, and/or the
+        payload, and it may modify one or more headers and/or
+        the payload.  This may be done on the top level `Message`
+        object, or on any sub-object.
+
+    Finalization
+        The Model is converted into a unicode or binary stream,
+        or the model is discarded.
+
+
+
+Header Policy Control During Lifecycle
+--------------------------------------
+
+One of the major controls exerted by the Policy is the management of headers
+during the `Message` lifecycle.  Most applications don't need to be aware of
+this.
+
+A header enters the model in one of two ways: via a Parser, or by being set to
+a specific value by an application program after the Model already exists.
+Similarly, a header exits the model in one of two ways: by being serialized by
+a Generator, or by being retrieved from a Model by an application program.  The
+Policy object provides hooks for all four of these pathways.
+
+The model storage for headers is a list of (name, value) tuples.
+
+The Parser identifies headers during parsing, and passes them to the
+:meth:`~email.policy.Policy.header_source_parse` method of the Policy.  The
+result of that method is the (name, value) tuple to be stored in the model.
+
+When an application program supplies a header value (for example, through the
+`Message` object `__setitem__` interface), the name and the value are passed to
+the :meth:`~email.policy.Policy.header_store_parse` method of the Policy, which
+returns the (name, value) tuple to be stored in the model.
+
+When an application program retrieves a header (through any of the dict or list
+interfaces of `Message`), the name and value are passed to the
+:meth:`~email.policy.Policy.header_fetch_parse` method of the Policy to
+obtain the value returned to the application.
+
+When a Generator requests a header during serialization, the name and value are
+passed to the :meth:`~email.policy.Policy.fold` method of the Policy, which
+returns a string containing line breaks in the appropriate places.  The
+:meth:`~email.policy.Policy.cte_type` Policy control determines whether or
+not Content Transfer Encoding is performed on the data in the header.  There is
+also a :meth:`~email.policy.Policy.binary_fold` method for use by generators
+that produce binary output, which returns the folded header as binary data,
+possibly folded at different places than the corresponding string would be.
+
+
+Handling Binary Data
+--------------------
+
+In an ideal world all message data would conform to the RFCs, meaning that the
+parser could decode the message into the idealized unicode message that the
+sender originally wrote.  In the real world, the email package must also be
+able to deal with badly formatted messages, including messages containing
+non-ASCII characters that either have no indicated character set or are not
+valid characters in the indicated character set.
+
+Since email messages are *primarily* text data, and operations on message data
+are primarily text operations (except for binary payloads of course), the model
+stores all text data as unicode strings.  Un-decodable binary inside text
+data is handled by using the `surrogateescape` error handler of the ASCII
+codec.  As with the binary filenames the error handler was introduced to
+handle, this allows the email package to "carry" the binary data received
+during parsing along until the output stage, at which time it is regenerated
+in its original form.
+
+This carried binary data is almost entirely an implementation detail.  The one
+place where it is visible in the API is in the "internal" API.  A Parser must
+do the `surrogateescape` encoding of binary input data, and pass that data to
+the appropriate Policy method.  The "internal" interface used by the Generator
+to access header values preserves the `surrogateescaped` bytes.  All other
+interfaces convert the binary data either back into bytes or into a safe form
+(losing information in some cases).
+
+
+Backward Compatibility
+----------------------
+
+The :class:`~email.policy.Policy.Compat32` Policy provides backward
+compatibility with version 5.1 of the email package.  It does this via the
+following implementation of the four+1 Policy methods described above:
+
+header_source_parse
+    Splits the first line on the colon to obtain the name, discards any spaces
+    after the colon, and joins the remainder of the line with all of the
+    remaining lines, preserving the linesep characters to obtain the value.
+    Trailing carriage return and/or linefeed characters are stripped from the
+    resulting value string.
+
+header_store_parse
+    Returns the name and value exactly as received from the application.
+
+header_fetch_parse
+    If the value contains any `surrogateescaped` binary data, return the value
+    as a :class:`~email.header.Header` object, using the character set
+    `unknown-8bit`.  Otherwise just returns the value.
+
+fold
+    Uses :class:`~email.header.Header`'s folding to fold headers in the
+    same way the email5.1 generator did.
+
+binary_fold
+    Same as fold, but encodes to 'ascii'.
+
+
+New Algorithm
+-------------
+
+header_source_parse
+    Same as legacy behavior.
+
+header_store_parse
+    Same as legacy behavior.
+
+header_fetch_parse
+    If the value is already a header object, returns it.  Otherwise, parses the
+    value using the new parser, and returns the resulting object as the value.
+    `surrogateescaped` bytes get turned into unicode unknown character code
+    points.
+
+fold
+    Uses the new header folding algorithm, respecting the policy settings.
+    surrogateescaped bytes are encoded using the ``unknown-8bit`` charset for
+    ``cte_type=7bit`` or ``8bit``.  Returns a string.
+
+    At some point there will also be a ``cte_type=unicode``, and for that
+    policy fold will serialize the idealized unicode message with RFC-like
+    folding, converting any surrogateescaped bytes into the unicode
+    unknown character glyph.
+
+binary_fold
+    Uses the new header folding algorithm, respecting the policy settings.
+    surrogateescaped bytes are encoded using the `unknown-8bit` charset for
+    ``cte_type=7bit``, and get turned back into bytes for ``cte_type=8bit``.
+    Returns bytes.
+
+    At some point there will also be a ``cte_type=unicode``, and for that
+    policy binary_fold will serialize the message according to :rfc:``5335``.