eryksun added the comment:
>def __setattr__(cls, key, value):
>super(type(QMediaPlaylist), cls).__setattr__(cls, key, value)
>return
>
> The program segfaults when instantiating the Playlist class.
I'd expect a TypeError because of the extra cls argu
eryksun added the comment:
The result of str.split and str.rsplit can differ depending on the optional 2nd
parameter, maxsplit:
>>> 'a b c'.split(None, 1)
['a', 'b c']
>>> 'a b c'.rsplit(None, 1)
['a b
eryksun added the comment:
The changeset from 03 Dec is in the Windows 2.7.9 release.
Python 2.7.9 (default, Dec 10 2014, 12:28:03) [MSC v.1500 64 bit
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more
information
eryksun added the comment:
To check for a link on Windows, os.walk calls ntpath.islink, which calls
os.lstat. Currently the os.lstat implementation only sets S_IFLNK for symbolic
links. attribute_data_to_stat could also check for junctions
(IO_REPARSE_TAG_MOUNT_POINT). For consistency
eryksun added the comment:
The whence argument is used in a switch statement that handles SEEK_END and
SEEK_CUR. It doesn't raise an error for an invalid whence value. It just falls
through to the fsetpos call.
_portable_fseek
https://hg.python.org/cpython/file/648dcafa7e5f/Ob
eryksun added the comment:
This isn't a Python bug. The Windows console doesn't properly support UTF-8.
See issue 1602 and Drekin's win-unicode-console, an alternative REPL based on
the wide-character (UCS-2) console API.
FWIW, I attached a debugger to conhost.exe under Windo
eryksun added the comment:
For 3.5 this affects Windows as well, since the new CRT supports RFC1766
language codes, but only without a codepage spec:
Python 3.5.0a1 (v3.5.0a1:5d4b6a57d5fd, Feb 7 2015, 18:15:14)
[MSC v.1900 64 bit (AMD64)] on win32
Type "help",
eryksun added the comment:
Given super(cls, obj), cls needs to be somewhere in type(obj).__mro__. Thus the
implementation checks PyType_IsSubtype instead of the more generic
PyObject_IsSubclass.
In this case int's MRO is unrelated to numbers.Number:
>>> print(*int.__
eryksun added the comment:
> -setlocale should return nothing. It's a setter
> -getlocale should return a platform-specific locale specification,
> probably what is currently returned by setlocale. The output
> should be ready for consumption by setlocale.
These functions ar
eryksun added the comment:
Calling nt.execv works with a unicode string because it creates a bytes path
via PyUnicode_FSConverter. OTOH, nt.execve uses path_converter, which doesn't
convert unicode to bytes on Windows. Thus in posixmodule.c, for the call
execve(path->narrow, argvlist,
eryksun added the comment:
This looks like an oversight. In the implementation in [bltinmodule.c][1], if
checking sys.stdout.fileno() fails, it clears the error without setting tty =
0. It's the [same in 3.5][2].
/* We should only use (GNU) readline if Python's sys
eryksun added the comment:
In Python 2 [Py_InitModule4][1] optionally allows setting __self__ on module
functions, but no module in the standard library actually uses this. It's
always None. This is no longer optional with Python 3's [PyModule_Create][2].
Built-in module
eryksun added the comment:
>> python's DLL already has the necessary "complete manifest," right?
>
> In theory yes, but apparently it isn't working in this case. It
> needs more investigation to figure out why.
The manifest in the DLL is stored as resour
eryksun added the comment:
> shapely's installation instructions from windows are to use
> chris gohlke's prebuilt binaries from here:
> http://www.lfd.uci.edu/~gohlke/pythonlibs/
Christoph Gohlke's Shapely‑1.5.9‑cp27‑none‑win_amd64.whl includes a version of
geos
eryksun added the comment:
It works for me:
>>> open('test.c', 'w').write('long test(long x) {return x;}')
>>> os.system('gcc -shared -fPIC -o test.so test.c')
0
>>> test = CDLL('./test.so').test
&
eryksun added the comment:
I can't reproduce this in Windows 7 or 10 using Python 3.4. What gets printed
for the following?
import os
import subprocess
cmd32 = os.path.join(os.environ['SYSTEMROOT'], 'SysWOW64', 'cmd.exe')
subprocess.call('{} /c set S
eryksun added the comment:
> It seems only a minimal set of environment variables are set
Apparently the initial environment is empty. The values you see are defaults
set by cmd.exe when it starts. It also sets the 'hidden' variable "=C:" to the
current directory on
eryksun added the comment:
In Windows 10 ReadFile doesn't set ERROR_OPERATION_ABORTED (995) for Ctrl+C
when reading console input, but ReadConsole does.
>>> from ctypes import *
>>> kernel32 = WinDLL('kernel32', use_last_error=True)
>>&g
eryksun added the comment:
This is not a bug, but perhaps the documentation could further clarify that the
set of valid values for the mode parameter is platform dependent. The [POSIX
specification][1] for mkdir() states that "[w]hen bits in mode other than the
file permission bits ar
eryksun added the comment:
To support cross-platform shebangs, the launcher special-cases the following
virtual commands [1]:
/usr/bin/env python
/usr/bin/python
/usr/local/bin/python
python
The "env" virtual command searches the PATH environment variable. Note that
eryksun added the comment:
> This code can cause issues on Windows
What's the issue or issues here? For 2.7, Windows won't be able to find
msvcr90.dll without an activation context, but that's just an
ERROR_MOD_NOT_FOUND OS error. It should be ignored by the try/except b
eryksun added the comment:
> Actually, it finds the DLL fine and the DLL terminates the entire
> process when it fails to detect an activation context.
OK, in that case it finds msvcr90.dll via PATH. I was only thinking of the DLL
being installed in a subdirectory of the system
eryksun added the comment:
> That would break anyone else who's manually managing their own
> activation context around ctypes.
Since this can't be made to work automatically, I prefer your suggestion to
continue checking for uuid.dll. You could just do something li
eryksun added the comment:
> windll.python27._Py_ActivateActCtx would suffice
It would instead be ctypes.pythonapi._Py_ActivateActCtx -- if the DLL exported
a function with this name. ctypes.pythonapi is a PyDLL instance that wraps
sys.dllhandle.
I think it would be more useful in gene
eryksun added the comment:
Reassigning "f" closes the first file object, but not before the second file
object gets created. You can write to the already-closed file, assuming the
write is small enough to not flush the FILE stream buffer (e.g. "beer", given
an empty 4
eryksun added the comment:
The permission error comes from calling SetHandleInformation on an invalid
socket value. The code shouldn't make it that far. The problem starts earlier
in sock_accept_impl. This function checks whether SOCKET_T ctx->result is
non-negative to determine whe
eryksun added the comment:
LGTM on Windows 7:
Python 3.5.0b4+ (default, Jul 27 2015, 17:46:34) [MSC v.1900 64 bit
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>
eryksun added the comment:
The problem is that the 3rd party [lockfile][1] module assumes that if os.link
exists it means hard links are supported for all file systems on a given
platform. So in your case it gets stuck repeatedly trying an operation that can
never succeed. This can probably
eryksun added the comment:
I think the window to change this is closed. Section 16.16.2.7 in the docs
states that for c_int "no overflow checking is done". I'm sure there's code
that relies on that behavior, just as I'm sure there's code that relies on it
for
eryksun added the comment:
I think a custom action can be added to Tools/msi/msisupport.c to send a
[WM_SETTINGCHANGE][1] "Environment" message to top-level windows. This makes
Explorer reload its environment from the registry, so starting a new command
prompt (cmd.exe) from Explore
eryksun added the comment:
On Windows, using the shell's [Known Folders API][1] is preferred. For Python
3.6+, an extension module could wrap SHGetKnownFolderPath and provide a dict of
KNOWNFOLDERID values such as FOLDERID_RoamingAppData.
On Linux, there's the [XDG Base
eryksun added the comment:
64-bit 3.5.0b4 works for me in Windows 7. Try loading _tkinter.pyd in
[Dependency Walker][1]. Or try loading the dependent DLLs directly via ctypes:
import os
import _ctypes
dlls_path = os.path.dirname(_ctypes.__file__)
for d in ('tcl86
eryksun added the comment:
Not finding python35.dll is normal since there's no activation context from
python.exe. The vcruntime140 library is statically linked to avoid having to
distribute vcruntime140.dll. See issue 24476. This needs to be changed in the
TCL/Tk project files as
eryksun added the comment:
That's a vestige of the 2.x docs. For 3.x it should be
"create_string_buffer(aBytes, anInteger)".
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python, eryksun
versions: +Pyth
eryksun added the comment:
Popen calls Windows [CreateProcess][1]. If the Popen "executable" argument
isn't used or if the file from the command line doesn't include a directory
path, then CreateProcess searches for it in the following directories:
1. The dire
eryksun added the comment:
> If exec gets two separate objects as globals and locals,
> the code will be executed as if it were embedded in a
> class definition.
Probably there needs to be more clarification of the compilation context. Class
definitions support lexical closures
eryksun added the comment:
A functional memoryview for ctypes objects would avoid having to use
workarounds, such as the following:
>>> d = ctypes.c_double()
>>> b = (ctypes.c_char * ctypes.sizeof(d)).from_buffer(d)
>>> b[:] = b'abcdefgh'
&
eryksun added the comment:
This is a 3rd party issue with the pyreadline module, which already has an open
ticket for this problem:
https://github.com/pyreadline/pyreadline/issues/30
--
nosy: +eryksun
___
Python tracker
<http://bugs.python.
eryksun added the comment:
Not every buffer is null-terminated. That's just the assumption used if the
size isn't specified. The documentation can possibly be reworded to make this
clearer, but the function itself shouldn't be changed.
--
assignee: -> docs
Changes by eryksun :
--
resolution: -> duplicate
status: open -> closed
superseder: -> Python interactive console doesn't use sys.stdin for input
___
Python tracker
<http://bugs.pyth
eryksun added the comment:
Your .py file association isn't configured to pass command-line arguments.
Revert to using the "Python.File" type that was created by Python's installer.
The associated command should be something like
"C:\Windows\py.exe" "%
eryksun added the comment:
> My py_auto_file association
Oh, it's that auto filetype again. Steve, when you say you fixed this for 3.5,
does that means there's a simple command or API to revert this automatic ProgId
back to the Python.File type? This problem shows up repeat
Changes by eryksun :
--
versions: +Python 3.4 -Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issue24843>
___
___
Python-bugs-list mailin
Changes by eryksun :
--
resolution: -> not a bug
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue24843>
___
___
Python-bugs-list
eryksun added the comment:
You're passing re.UNICODE (32) as the value of the count parameter, i.e. the
function signature is re.sub(pattern, repl, string, count=0, flags=0).
--
nosy: +eryksun
resolution: -> not a bug
status: open -
eryksun added the comment:
It seems you want a BigEndianStructure:
from ctypes import *
class SAEJ1939MsgId(BigEndianStructure):
_fields_ = (('reserved', c_uint8, 3),
('priority', c_uint8, 3),
eryksun added the comment:
No, ctypes.Structure should use native endianness. So on a little-endian it's
the same as ctypes.LittleEndianStructure, and on a big-endian system it's the
same as ctypes.BigEndianStructure. ARM processors can work in either mode.
IIRC, the Raspberry Pi i
eryksun added the comment:
The patch for issue 23465 (PEP 486) updated the docs to explain the behavior of
#!/usr/bin/env as follows:
The /usr/bin/env form of shebang line has one further special
property. Before looking for installed Python interpreters,
this form will search the
eryksun added the comment:
Refer to section 6.2.3, parenthesized forms:
https://docs.python.org/3/reference/expressions.html#parenthesized-forms
if the list contains at least one comma, it yields a tuple;
otherwise, it yields the single expression that makes up the
expression list
eryksun added the comment:
Albert, this issue was opened for Python 2.4 and was closed over 6 years ago.
Open a new issue if you believe there's a bug or room for improvement in a
currently supported Python version.
FYI, on Windows _PyOS_URandom first initializes the Crypto API by ca
eryksun added the comment:
I forgot to set errcheck:
import ctypes
userenv = ctypes.WinDLL('userenv', use_last_error=True)
def errcheck_bool(result, func, args):
if not result:
raise ctypes.WinError(ctypes.get_last_error())
r
eryksun added the comment:
Within the standard library, I think only the site module uses the top-level
sysconfig module, which IIRC it uses to set up sys.path.
Note that WINDOWS_SCHEME in distutils.command.install uses "Include". Also for
virtual en
eryksun added the comment:
> It is not clear why the absence of _setmode(fd, os.O_BINARY)
> is not detected by tests.
It's only a problem when an existing text-mode file descriptor is passed in.
For example, in text mode the CRT handles b'\x1a' as an EOF marker:
Pyt
eryksun added the comment:
The 3.5 build uses MSVC 14 (VS 2015):
https://docs.python.org/3.5/using/windows.html#compiling-python-on-windows
https://hg.python.org/cpython/file/3.5/PCbuild/readme.txt
--
nosy: +eryksun
___
Python tracker
<h
eryksun added the comment:
I expect Popen's shell=True option to use the same shell as os.system. The
POSIX spec for the [system function][1] requires running sh, as follows:
execl(, "sh", "-c", command, (char *)0);
glibc uses "/bin/sh" for the shell pa
eryksun added the comment:
Here's the rationale given for ignoring SHELL in POSIX system():
One reviewer suggested that an implementation of system() might
want to use an environment variable such as SHELL to determine
which command interpreter to use. The supposed implement
eryksun added the comment:
FYI, the size of the terminal associated with the C's stdout isn't related to
the IDLE shell. For example, in Linux when I run IDLE from the GUI, the
associated terminal size is 0x0.
On Windows, os.get_terminal_size uses the console API
GetConsoleScreen
eryksun added the comment:
> If you dropped the isatty() check for stdout in Linux, you may
> end up with the output of Readline in the file (assuming
> Readline is okay with this). The file would include all the
> cursor positioning codes, backspaces, etc, that Readline
> g
eryksun added the comment:
Maybe the problem is using escape characters (0x1b) instead of \e. Try using
the following:
"\e[5~": history-search-backward
FWIW, your inputrc doesn't crash my system (64-bit Linux, readline 6.3 and
Python 3.4).
------
eryksun added the comment:
A gdb backtrace may be of more help than strace.
--
___
Python tracker
<http://bugs.python.org/issue24958>
___
___
Python-bugs-list m
eryksun added the comment:
Did you mark the variable for export in your shell? For example:
$ v=1
$ python -c 'import os;print os.environ.get("v")'
None
$ export v
$ python -c 'import os;print os.environ.get("v"
eryksun added the comment:
> exception instance raised in __getattr__ should not lead
> to its another call but propagated to outer level
In this case the next outer level is your descriptor implementation. You have
to ensure it doesn't leak the AttrubuteError. Otherwise the
eryksun added the comment:
Do you mean the dst path has a trailing slash, but the directory doesn't exist?
shutil.copy doesn't check for a trailing slash, so it attempts to open dst as a
regular file. On Linux, and probably most POSIX systems, this results in an
EISDIR (is a direct
Changes by eryksun :
--
keywords: +easy
priority: normal -> low
versions: +Python 3.4, Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issu
eryksun added the comment:
> On Windows, the C lib strftime() segfaults with a trailing '%',
> just as it does with unsupported format codes.
No, it doesn't segfault; it invokes the invalid parameter handler (IPH). This
could always be configured for the whole process,
eryksun added the comment:
> Rather than debating about how various platforms handle malformed
> format strings for strftime(), and whether or not they crash, we
> should simply prevent the native strftime() function from seeing
> them in the first place.
Of course the check
eryksun added the comment:
There's a public method that's almost what you want:
>>> print(pathlib.Path.absolute.__doc__)
Return an absolute version of this path. This function works
even if the path doesn't point to anything.
No normali
eryksun added the comment:
> MSVC seems somewhat inconsistent about its response:
> >>> strftime('aaa%')
> ''
That's not due to MSVC. It's setting errno to EINVAL. The problem is that
time_strftime is testing (buflen > 0 || i >= 256 * fm
eryksun added the comment:
With MSVC, if errno is cleared before calling strftime, then when buflen == 0
you know whether it's an invalid format string (EINVAL) or maxsize is too small
(ERANGE). There's no need to guess. Oddly, only EINVAL is documented, even
though setting ERANGE h
eryksun added the comment:
It seems VC 14 has a bug here. In the new C runtime, strftime is implemented by
calling wcsftime as follows:
size_t const result = _Wcsftime_l(wstring.get(), maxsize, wformat.get(),
timeptr, lc_time_arg, locale);
if (result == 0)
return 0
eryksun added the comment:
Steve, it seems to me that for MSVC the EINVAL test should come first:
_Py_BEGIN_SUPPRESS_IPH
olderr = errno;
errno = 0;
buflen = format_time(outbuf, i, fmt, &buf);
err = errno;
errno = olderr;
_Py_END_SUPPRESS_IPH
if (bu
eryksun added the comment:
I think 3.5 should be distributed with vcruntime140.dll. It seems a waste for
python.exe, python35.dll, and all of the extension modules and dependent DLLs
to each take an FLS slot:
>>> import ctypes # +1 for _ctypes
>>> kernel32 = ctype
eryksun added the comment:
You're passing an already decoded string, so the BOM is treated as text.
Instead open the file in binary mode, i.e. open("bom3.py", "rb"). This way the
BOM will be detected when decoding the source bytes. Here's an example that
passe
eryksun added the comment:
The latest version that supports Windows XP is 3.4.3.
--
components: +IDLE -Windows
nosy: +eryksun
___
Python tracker
<http://bugs.python.org/issue25
Changes by eryksun :
--
components: +Windows -IDLE
___
Python tracker
<http://bugs.python.org/issue25107>
___
___
Python-bugs-list mailing list
Unsubscribe:
eryksun added the comment:
> errno should always be cleared before use (in C99 at least,
> not sure what the crt does).
The CRT's strftime doesn't clear errno. I suggested clearing it in issue 25029,
msg250215.
------
nosy: +eryksun
__
eryksun added the comment:
> Is there a way people can set errno to zero from Python code?
> Or do we need to ship 3.5.1 already?
The only the thing that comes to mind is using ctypes based on the CRT's
implementation of errno:
import ctypes
import errno
import time
eryksun added the comment:
But it should go without saying that clearing errno from Python isn't reliable
considering how much code executes between Python statements. It needs to be
cleared right before call strftime, and optionally the old value needs to be
saved first in order to re
eryksun added the comment:
This bug is due to issue 23285, which improved support for EINTR handling.
os_waitpid_impl was changed to use the following do-while loop:
do {
Py_BEGIN_ALLOW_THREADS
res = _cwait(&status, pid, options);
Py_END_ALLOW_THREADS
} w
eryksun added the comment:
Maybe the download page should direct XP users to install 3.4.x.
--
nosy: +eryksun
___
Python tracker
<http://bugs.python.org/issue25
eryksun added the comment:
virtualenv fails to copy vcruntime140.dll. Use the standard library's venv
module instead.
--
nosy: +eryksun
resolution: -> third party
stage: -> resolved
status: open -> closed
___
Python
eryksun added the comment:
The issue as I understand it is that, on this particular Windows 8.1 system,
passing a non-NULL lpEnvironment to CreateProcess works when starting a native
64-bit executable, but fails when starting a 32-bit executable via the WOW64
system. The child process instead
eryksun added the comment:
There should be a bunch of logs named "Python 3.5.0*.log" in your user's %TEMP%
directory. If you don't mind, zip them up and attach the file to this issue for
Steve Dower to review when he returns from vacation.
In the mean time, try dir
eryksun added the comment:
> Pre-compiling should generally not be needed
It's a useful optimization if Python is installed to a directory that doesn't
grant write access to regular users, such as %ProgramFiles%.
--
___
Python t
eryksun added the comment:
Per "Python 3.5.0 (32-bit)_20150914055131.log", the installer detects the OS as
NT 6.2.9200 (Windows 8/Server 2012), and installs Windows8-RT-KB2999226-x64.msu.
[0A68:0EC8][2015-09-14T05:51:31]i001:
Burn v3.10.0.1823,
Windows v6.2 (
eryksun added the comment:
To decode the tzname strings, Python calls mbstowcs, which on Windows uses
Latin-1 in the "C" locale. However, in this locale the tzname strings are
actually encoded using the system ANSI codepage (e.g. 1250 for Central/Eastern
Europe). So it ends up dec
eryksun added the comment:
> This looks as a duplicate of issue2528.
No, yangyanbo's problem is unrelated to the file's security descriptor, and
it's not a bug.
telnet.exe is manually installed via "Programs and Features", which only
installs a 64-bit version into
eryksun added the comment:
See issue 16597. This wasn't fixed for 3.2, so it won't close the file if
flush() fails. You'll either have to work around this or upgrade to 3.3+.
------
nosy: +eryksun
resolution: -> out of date
stage: -> resolved
s
eryksun added the comment:
Lauri changed the version from 3.4 to 3.2, and I was able to reproduce the
problem in 3.2.5:
C:\Temp>py -3.2 --version
Python 3.2.5
C:\Temp>py -3.2 nospace.py
removing fill.txt
Traceback (most recent call last):
File "nospace.py&q
eryksun added the comment:
> local_encoding = locale.getdefaultlocale()[1]
Use locale.getpreferredencoding().
> b = eval('b' + ascii(result))
> result = b.decode(local_encoding)
It's simpler and more reliable to use 'latin-1' and 'mbcs' (ANSI). For
eryksun added the comment:
The name can be any str/unicode string, including language keywords:
>>> setattr(o, 'def', 'allowed')
>>> getattr(o, 'def')
'allowed'
>>> o.def
File "", line 1
eryksun added the comment:
To clarify using a unicode name in 2.x, it has to be encodable using the
default encoding, sys.getdefaultencoding(). Normally this is ASCII.
--
___
Python tracker
<http://bugs.python.org/issue25
eryksun added the comment:
> import locale
> locale.setlocale(locale.LC_ALL, '')
>
> import importlib
> import time
> importlib.reload(time)
>
> it does not work when imported after importing time.
> What is the reason? Does reload() work only for
>
eryksun added the comment:
This issue doesn't pertain to the 64-bit version.
C:\Temp>py -3.5
Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:27:37)
[MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "li
eryksun added the comment:
This is a documentation issue and not specific to a particular version of
Python. What's the rule on version tagging in this case?
--
components: +Documentation
___
Python tracker
<http://bugs.python.org/is
eryksun added the comment:
> The problem here is probably that installing the CRT update
> required a restart
I saw that, but it didn't make any sense to me that the DLL isn't available
immediately after wusa.exe exits. Is it in limbo until the system is restarted?
I know in
eryksun added the comment:
Where is the API documented to change the install scope dynamically? I see
where it's apparently defined in the burn manifest (extracted from the
executable) as PerMachine="no":
http://schemas.microsoft.com/wix/2008/Burn";>
<
eryksun added the comment:
Even MvL appears to slip up when he states "some may accept non-strings as
attribute names". That would be pointless in a __setattr__ method since setattr
/ PyObject_SetAttr reject non-string values
eryksun added the comment:
Also, why does the per-user install path have a seemingly pointless "Python"
base directory? I expected it to install directly into
FOLDERID_UserProgramFiles, to be consistent with installing to
FOLDERID_ProgramFiles.
Also, I doubt anyone cares, but t
eryksun added the comment:
Try directly installing the Universal CRT update,
[Windows6.0-KB2999226-x86.msu][1]. Run it with the /log option, e.g.
Windows6.0-KB2999226-x86.msu /log:kb2999226.evtx
You can view this log in the Windows event viewer, or convert it to text XML on
the command
101 - 200 of 293 matches
Mail list logo
