forked from python/python-docs-es
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathcporting.po
More file actions
195 lines (167 loc) · 6.78 KB
/
cporting.po
File metadata and controls
195 lines (167 loc) · 6.78 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2001-2019, Python Software Foundation
# This file is distributed under the same license as the Python package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Python 3.7\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2019-05-06 11:59-0400\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../Doc/howto/cporting.rst:7
msgid "Porting Extension Modules to Python 3"
msgstr ""
#: ../Doc/howto/cporting.rst:0
msgid "author"
msgstr ""
#: ../Doc/howto/cporting.rst:9
msgid "Benjamin Peterson"
msgstr ""
#: ../Doc/howto/cporting.rst:None
msgid "Abstract"
msgstr ""
#: ../Doc/howto/cporting.rst:14
msgid ""
"Although changing the C-API was not one of Python 3's objectives, the many "
"Python-level changes made leaving Python 2's API intact impossible. In "
"fact, some changes such as :func:`int` and :func:`long` unification are more "
"obvious on the C level. This document endeavors to document "
"incompatibilities and how they can be worked around."
msgstr ""
#: ../Doc/howto/cporting.rst:23
msgid "Conditional compilation"
msgstr ""
#: ../Doc/howto/cporting.rst:25
msgid ""
"The easiest way to compile only some code for Python 3 is to check if :c:"
"macro:`PY_MAJOR_VERSION` is greater than or equal to 3. ::"
msgstr ""
#: ../Doc/howto/cporting.rst:32
msgid ""
"API functions that are not present can be aliased to their equivalents "
"within conditional blocks."
msgstr ""
#: ../Doc/howto/cporting.rst:37
msgid "Changes to Object APIs"
msgstr ""
#: ../Doc/howto/cporting.rst:39
msgid ""
"Python 3 merged together some types with similar functions while cleanly "
"separating others."
msgstr ""
#: ../Doc/howto/cporting.rst:44
msgid "str/unicode Unification"
msgstr ""
#: ../Doc/howto/cporting.rst:46
msgid ""
"Python 3's :func:`str` type is equivalent to Python 2's :func:`unicode`; the "
"C functions are called ``PyUnicode_*`` for both. The old 8-bit string type "
"has become :func:`bytes`, with C functions called ``PyBytes_*``. Python 2.6 "
"and later provide a compatibility header, :file:`bytesobject.h`, mapping "
"``PyBytes`` names to ``PyString`` ones. For best compatibility with Python "
"3, :c:type:`PyUnicode` should be used for textual data and :c:type:`PyBytes` "
"for binary data. It's also important to remember that :c:type:`PyBytes` "
"and :c:type:`PyUnicode` in Python 3 are not interchangeable like :c:type:"
"`PyString` and :c:type:`PyUnicode` are in Python 2. The following example "
"shows best practices with regards to :c:type:`PyUnicode`, :c:type:"
"`PyString`, and :c:type:`PyBytes`. ::"
msgstr ""
#: ../Doc/howto/cporting.rst:95
msgid "long/int Unification"
msgstr ""
#: ../Doc/howto/cporting.rst:97
msgid ""
"Python 3 has only one integer type, :func:`int`. But it actually "
"corresponds to Python 2's :func:`long` type—the :func:`int` type used in "
"Python 2 was removed. In the C-API, ``PyInt_*`` functions are replaced by "
"their ``PyLong_*`` equivalents."
msgstr ""
#: ../Doc/howto/cporting.rst:104
msgid "Module initialization and state"
msgstr ""
#: ../Doc/howto/cporting.rst:106
msgid ""
"Python 3 has a revamped extension module initialization system. (See :pep:"
"`3121`.) Instead of storing module state in globals, they should be stored "
"in an interpreter specific structure. Creating modules that act correctly "
"in both Python 2 and Python 3 is tricky. The following simple example "
"demonstrates how. ::"
msgstr ""
#: ../Doc/howto/cporting.rst:197
msgid "CObject replaced with Capsule"
msgstr ""
#: ../Doc/howto/cporting.rst:199
msgid ""
"The :c:type:`Capsule` object was introduced in Python 3.1 and 2.7 to "
"replace :c:type:`CObject`. CObjects were useful, but the :c:type:`CObject` "
"API was problematic: it didn't permit distinguishing between valid CObjects, "
"which allowed mismatched CObjects to crash the interpreter, and some of its "
"APIs relied on undefined behavior in C. (For further reading on the "
"rationale behind Capsules, please see :issue:`5630`.)"
msgstr ""
#: ../Doc/howto/cporting.rst:206
msgid ""
"If you're currently using CObjects, and you want to migrate to 3.1 or newer, "
"you'll need to switch to Capsules. :c:type:`CObject` was deprecated in 3.1 "
"and 2.7 and completely removed in Python 3.2. If you only support 2.7, or "
"3.1 and above, you can simply switch to :c:type:`Capsule`. If you need to "
"support Python 3.0, or versions of Python earlier than 2.7, you'll have to "
"support both CObjects and Capsules. (Note that Python 3.0 is no longer "
"supported, and it is not recommended for production use.)"
msgstr ""
#: ../Doc/howto/cporting.rst:216
msgid ""
"The following example header file :file:`capsulethunk.h` may solve the "
"problem for you. Simply write your code against the :c:type:`Capsule` API "
"and include this header file after :file:`Python.h`. Your code will "
"automatically use Capsules in versions of Python with Capsules, and switch "
"to CObjects when Capsules are unavailable."
msgstr ""
#: ../Doc/howto/cporting.rst:223
msgid ""
":file:`capsulethunk.h` simulates Capsules using CObjects. However, :c:type:"
"`CObject` provides no place to store the capsule's \"name\". As a result "
"the simulated :c:type:`Capsule` objects created by :file:`capsulethunk.h` "
"behave slightly differently from real Capsules. Specifically:"
msgstr ""
#: ../Doc/howto/cporting.rst:228
msgid "The name parameter passed in to :c:func:`PyCapsule_New` is ignored."
msgstr ""
#: ../Doc/howto/cporting.rst:230
msgid ""
"The name parameter passed in to :c:func:`PyCapsule_IsValid` and :c:func:"
"`PyCapsule_GetPointer` is ignored, and no error checking of the name is "
"performed."
msgstr ""
#: ../Doc/howto/cporting.rst:234
msgid ":c:func:`PyCapsule_GetName` always returns NULL."
msgstr ""
#: ../Doc/howto/cporting.rst:236
msgid ""
":c:func:`PyCapsule_SetName` always raises an exception and returns failure. "
"(Since there's no way to store a name in a CObject, noisy failure of :c:func:"
"`PyCapsule_SetName` was deemed preferable to silent failure here. If this "
"is inconvenient, feel free to modify your local copy as you see fit.)"
msgstr ""
#: ../Doc/howto/cporting.rst:243
msgid ""
"You can find :file:`capsulethunk.h` in the Python source distribution as :"
"source:`Doc/includes/capsulethunk.h`. We also include it here for your "
"convenience:"
msgstr ""
#: ../Doc/howto/cporting.rst:252
msgid "Other options"
msgstr ""
#: ../Doc/howto/cporting.rst:254
msgid ""
"If you are writing a new extension module, you might consider `Cython "
"<http://cython.org/>`_. It translates a Python-like language to C. The "
"extension modules it creates are compatible with Python 3 and Python 2."
msgstr ""