# 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/faq/windows.rst:9

msgid "Python on Windows FAQ"

msgstr ""

#: ../Doc/faq/windows.rst:12

msgid "Contents"

msgstr ""

#: ../Doc/faq/windows.rst:22

msgid "How do I run a Python program under Windows?"

msgstr ""

#: ../Doc/faq/windows.rst:24

msgid ""

"This is not necessarily a straightforward question. If you are already "

"familiar with running programs from the Windows command line then everything "

"will seem obvious; otherwise, you might need a little more guidance."

msgstr ""

#: ../Doc/faq/windows.rst:28

msgid ""

"Unless you use some sort of integrated development environment, you will end "

"up *typing* Windows commands into what is variously referred to as a \"DOS "

"window\" or \"Command prompt window\". Usually you can create such a window "

"from your search bar by searching for ``cmd``. You should be able to "

"recognize when you have started such a window because you will see a Windows "

"\"command prompt\", which usually looks like this:"

msgstr ""

#: ../Doc/faq/windows.rst:39

msgid ""

"The letter may be different, and there might be other things after it, so "

"you might just as easily see something like:"

msgstr ""

#: ../Doc/faq/windows.rst:46

msgid ""

"depending on how your computer has been set up and what else you have "

"recently done with it. Once you have started such a window, you are well on "

"the way to running Python programs."

msgstr ""

#: ../Doc/faq/windows.rst:50

msgid ""

"You need to realize that your Python scripts have to be processed by another "

"program called the Python *interpreter*. The interpreter reads your script, "

"compiles it into bytecodes, and then executes the bytecodes to run your "

"program. So, how do you arrange for the interpreter to handle your Python?"

msgstr ""

#: ../Doc/faq/windows.rst:55

msgid ""

"First, you need to make sure that your command window recognises the word "

"\"py\" as an instruction to start the interpreter. If you have opened a "

"command window, you should try entering the command ``py`` and hitting "

"return:"

msgstr ""

#: ../Doc/faq/windows.rst:64

msgid "You should then see something like:"

msgstr ""

#: ../Doc/faq/windows.rst:72

msgid ""

"You have started the interpreter in \"interactive mode\". That means you can "

"enter Python statements or expressions interactively and have them executed "

"or evaluated while you wait. This is one of Python's strongest features. "

"Check it by entering a few expressions of your choice and seeing the results:"

msgstr ""

#: ../Doc/faq/windows.rst:84

msgid ""

"Many people use the interactive mode as a convenient yet highly programmable "

"calculator. When you want to end your interactive Python session, call the :"

"func:`exit` function or hold the :kbd:`Ctrl` key down while you enter a :kbd:"

"`Z`, then hit the \":kbd:`Enter`\" key to get back to your Windows command "

"prompt."

msgstr ""

#: ../Doc/faq/windows.rst:90

msgid ""

"You may also find that you have a Start-menu entry such as :menuselection:"

"`Start --> Programs --> Python 3.x --> Python (command line)` that results "

"in you seeing the ``>>>`` prompt in a new window. If so, the window will "

"disappear after you call the :func:`exit` function or enter the :kbd:`Ctrl-"

"Z` character; Windows is running a single \"python\" command in the window, "

"and closes it when you terminate the interpreter."

msgstr ""

#: ../Doc/faq/windows.rst:97

msgid ""

"Now that we know the ``py`` command is recognized, you can give your Python "

"script to it. You'll have to give either an absolute or a relative path to "

"the Python script. Let's say your Python script is located in your desktop "

"and is named ``hello.py``, and your command prompt is nicely opened in your "

"home directory so you're seeing something similar to::"

msgstr ""

#: ../Doc/faq/windows.rst:106

msgid ""

"So now you'll ask the ``py`` command to give your script to Python by typing "

"``py`` followed by your script path::"

msgstr ""

#: ../Doc/faq/windows.rst:114

msgid "How do I make Python scripts executable?"

msgstr ""

#: ../Doc/faq/windows.rst:116

msgid ""

"On Windows, the standard Python installer already associates the .py "

"extension with a file type (Python.File) and gives that file type an open "

"command that runs the interpreter (``D:\\Program Files\\Python\\python.exe "

"\"%1\" %*``). This is enough to make scripts executable from the command "

"prompt as 'foo.py'. If you'd rather be able to execute the script by simple "

"typing 'foo' with no extension you need to add .py to the PATHEXT "

"environment variable."

msgstr ""

#: ../Doc/faq/windows.rst:124

msgid "Why does Python sometimes take so long to start?"

msgstr ""

#: ../Doc/faq/windows.rst:126

msgid ""

"Usually Python starts very quickly on Windows, but occasionally there are "

"bug reports that Python suddenly begins to take a long time to start up. "

"This is made even more puzzling because Python will work fine on other "

"Windows systems which appear to be configured identically."

msgstr ""

#: ../Doc/faq/windows.rst:131

msgid ""

"The problem may be caused by a misconfiguration of virus checking software "

"on the problem machine. Some virus scanners have been known to introduce "

"startup overhead of two orders of magnitude when the scanner is configured "

"to monitor all reads from the filesystem. Try checking the configuration of "

"virus scanning software on your systems to ensure that they are indeed "

"configured identically. McAfee, when configured to scan all file system read "

"activity, is a particular offender."

msgstr ""

#: ../Doc/faq/windows.rst:141

msgid "How do I make an executable from a Python script?"

msgstr ""

#: ../Doc/faq/windows.rst:143

msgid ""

"See `cx_Freeze <https://anthony-tuininga.github.io/cx_Freeze/>`_ for a "

"distutils extension that allows you to create console and GUI executables "

"from Python code. `py2exe <http://www.py2exe.org/>`_, the most popular "

"extension for building Python 2.x-based executables, does not yet support "

"Python 3 but a version that does is in development."

msgstr ""

#: ../Doc/faq/windows.rst:151

msgid "Is a ``*.pyd`` file the same as a DLL?"

msgstr ""

#: ../Doc/faq/windows.rst:153

msgid ""

"Yes, .pyd files are dll's, but there are a few differences. If you have a "

"DLL named ``foo.pyd``, then it must have a function ``PyInit_foo()``. You "

"can then write Python \"import foo\", and Python will search for foo.pyd (as "

"well as foo.py, foo.pyc) and if it finds it, will attempt to call "

"``PyInit_foo()`` to initialize it. You do not link your .exe with foo.lib, "

"as that would cause Windows to require the DLL to be present."

msgstr ""

#: ../Doc/faq/windows.rst:160

msgid ""

"Note that the search path for foo.pyd is PYTHONPATH, not the same as the "

"path that Windows uses to search for foo.dll. Also, foo.pyd need not be "

"present to run your program, whereas if you linked your program with a dll, "

"the dll is required. Of course, foo.pyd is required if you want to say "

"``import foo``. In a DLL, linkage is declared in the source code with "

"``__declspec(dllexport)``. In a .pyd, linkage is defined in a list of "

"available functions."

msgstr ""

#: ../Doc/faq/windows.rst:169

msgid "How can I embed Python into a Windows application?"

msgstr ""

#: ../Doc/faq/windows.rst:171

msgid ""

"Embedding the Python interpreter in a Windows app can be summarized as "

"follows:"

msgstr ""

#: ../Doc/faq/windows.rst:173

msgid ""

"Do _not_ build Python into your .exe file directly. On Windows, Python must "

"be a DLL to handle importing modules that are themselves DLL's. (This is "

"the first key undocumented fact.) Instead, link to :file:`python{NN}.dll`; "

"it is typically installed in ``C:\\Windows\\System``. *NN* is the Python "

"version, a number such as \"33\" for Python 3.3."

msgstr ""

#: ../Doc/faq/windows.rst:179

msgid ""

"You can link to Python in two different ways. Load-time linking means "

"linking against :file:`python{NN}.lib`, while run-time linking means linking "

"against :file:`python{NN}.dll`. (General note: :file:`python{NN}.lib` is "

"the so-called \"import lib\" corresponding to :file:`python{NN}.dll`. It "

"merely defines symbols for the linker.)"

msgstr ""

#: ../Doc/faq/windows.rst:185

msgid ""

"Run-time linking greatly simplifies link options; everything happens at run "

"time. Your code must load :file:`python{NN}.dll` using the Windows "

"``LoadLibraryEx()`` routine. The code must also use access routines and "

"data in :file:`python{NN}.dll` (that is, Python's C API's) using pointers "

"obtained by the Windows ``GetProcAddress()`` routine. Macros can make using "

"these pointers transparent to any C code that calls routines in Python's C "

"API."

msgstr ""

#: ../Doc/faq/windows.rst:192

msgid ""

"Borland note: convert :file:`python{NN}.lib` to OMF format using Coff2Omf."

"exe first."

msgstr ""

#: ../Doc/faq/windows.rst:197

msgid ""

"If you use SWIG, it is easy to create a Python \"extension module\" that "

"will make the app's data and methods available to Python. SWIG will handle "

"just about all the grungy details for you. The result is C code that you "

"link *into* your .exe file (!) You do _not_ have to create a DLL file, and "

"this also simplifies linking."

msgstr ""

#: ../Doc/faq/windows.rst:203

msgid ""

"SWIG will create an init function (a C function) whose name depends on the "

"name of the extension module. For example, if the name of the module is "

"leo, the init function will be called initleo(). If you use SWIG shadow "

"classes, as you should, the init function will be called initleoc(). This "

"initializes a mostly hidden helper class used by the shadow class."

msgstr ""

#: ../Doc/faq/windows.rst:209

msgid ""

"The reason you can link the C code in step 2 into your .exe file is that "

"calling the initialization function is equivalent to importing the module "

"into Python! (This is the second key undocumented fact.)"

msgstr ""

#: ../Doc/faq/windows.rst:213

msgid ""

"In short, you can use the following code to initialize the Python "

"interpreter with your extension module."

msgstr ""

#: ../Doc/faq/windows.rst:224

msgid ""

"There are two problems with Python's C API which will become apparent if you "

"use a compiler other than MSVC, the compiler used to build pythonNN.dll."

msgstr ""

#: ../Doc/faq/windows.rst:227

msgid ""

"Problem 1: The so-called \"Very High Level\" functions that take FILE * "

"arguments will not work in a multi-compiler environment because each "

"compiler's notion of a struct FILE will be different. From an "

"implementation standpoint these are very _low_ level functions."

msgstr ""

#: ../Doc/faq/windows.rst:232

msgid ""

"Problem 2: SWIG generates the following code when generating wrappers to "

"void functions:"

msgstr ""

#: ../Doc/faq/windows.rst:241

msgid ""

"Alas, Py_None is a macro that expands to a reference to a complex data "

"structure called _Py_NoneStruct inside pythonNN.dll. Again, this code will "

"fail in a mult-compiler environment. Replace such code by:"

msgstr ""

#: ../Doc/faq/windows.rst:249

msgid ""

"It may be possible to use SWIG's ``%typemap`` command to make the change "

"automatically, though I have not been able to get this to work (I'm a "

"complete SWIG newbie)."

msgstr ""

#: ../Doc/faq/windows.rst:253

msgid ""

"Using a Python shell script to put up a Python interpreter window from "

"inside your Windows app is not a good idea; the resulting window will be "

"independent of your app's windowing system. Rather, you (or the "

"wxPythonWindow class) should create a \"native\" interpreter window. It is "

"easy to connect that window to the Python interpreter. You can redirect "

"Python's i/o to _any_ object that supports read and write, so all you need "

"is a Python object (defined in your extension module) that contains read() "

"and write() methods."

msgstr ""

#: ../Doc/faq/windows.rst:262

msgid "How do I keep editors from inserting tabs into my Python source?"

msgstr ""

#: ../Doc/faq/windows.rst:264

msgid ""

"The FAQ does not recommend using tabs, and the Python style guide, :pep:`8`, "

"recommends 4 spaces for distributed Python code; this is also the Emacs "

"python-mode default."

msgstr ""

#: ../Doc/faq/windows.rst:268

msgid ""

"Under any editor, mixing tabs and spaces is a bad idea. MSVC is no "

"different in this respect, and is easily configured to use spaces: Take :"

"menuselection:`Tools --> Options --> Tabs`, and for file type \"Default\" "

"set \"Tab size\" and \"Indent size\" to 4, and select the \"Insert spaces\" "

"radio button."

msgstr ""

#: ../Doc/faq/windows.rst:273

msgid ""

"Python raises :exc:`IndentationError` or :exc:`TabError` if mixed tabs and "

"spaces are causing problems in leading whitespace. You may also run the :mod:"

"`tabnanny` module to check a directory tree in batch mode."

msgstr ""

#: ../Doc/faq/windows.rst:280

msgid "How do I check for a keypress without blocking?"

msgstr ""

#: ../Doc/faq/windows.rst:282

msgid ""

"Use the msvcrt module. This is a standard Windows-specific extension "

"module. It defines a function ``kbhit()`` which checks whether a keyboard "

"hit is present, and ``getch()`` which gets one character without echoing it."

msgstr ""