New submission from Alexey :
function xml.sax.saxutils.escape('\x00qweqwe<') returns '\x00qweqwe<'
\x00 did not escaped to �
is this is a correct behavior?
this is influences tools like xmpppy, which sends \x00 not encoded and leads to
xmpp error.
--
mes
Changes by Alexey :
--
components: +XML
___
Python tracker
<http://bugs.python.org/issue13648>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Alexey added the comment:
sorry, xmpppy uses it's own escape method, but anyway... :)
--
___
Python tracker
<http://bugs.python.org/issue13648>
___
___
Pytho
Alexey added the comment:
Is interesting, that in win10 the bug is not reproduced too !
(only in win7!!!)
--
___
Python tracker
<https://bugs.python.org/issue45
Change by Alexey :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue45398>
___
___
Python-bugs-list
New submission from Alexey :
The _tunnel method of the HTTPConnection class in the http.client module, if
the CONNECT request is unsuccessful, closes the connection and raises an
OSError without returning the response data. This behavior does not allow to
implement the authentication
Change by Alexey :
--
nosy: +Namyotkin
___
Python tracker
<https://bugs.python.org/issue24964>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexey added the comment:
>This is correct behavior. \x00 is not supported in XML:
> not in raw form, and not in escaped form
last sentence in forth paragraph of section 1.3 in XML 1.1 specification says
following:
==
Due to potential problems with APIs,
#x0 is still forbidde
Alexey added the comment:
What am I trying to say is: if those characters are forbidden, then maybe they
need to be escaped rather than ignored?
--
___
Python tracker
<http://bugs.python.org/issue13
Alexey added the comment:
Please document this method.
I'm developing xmpp client using python 3.4 and it's ssl module. Stuck with
this same issue for a few days just because of a lack of documentation.
I'm asking you: why should I know about this method not from python
doc
New submission from Alexey:
Just one test failed for python-3.4.3
...
test_invalid_offset (test.test_os.TestSendfile) ... FAIL
...
--
files: test_os_log
messages: 236574
nosy: avoevodkin
priority: normal
severity: normal
status: open
title: test_os failed (python-3.4.3
New submission from Alexey Stepanov :
Documentation:
https://www.openssl.org/docs/manmaster/man3/OpenSSL_version_num.html
Python build fail with OpenSSL 3.0.1
(looks like OpenSSL broken deprecated API)
--
assignee: christian.heimes
components: SSL
messages: 408770
nosy
Alexey Stepanov added the comment:
Error example:
test_ssl: testing with 'OpenSSL 3.0.1 14 Dec 2021' (3, 0, 0, 1, 0)
...
AssertionError: False is not true : ('OpenSSL 3.0.1 14 Dec 2021', (3, 0, 0, 1,
0), '0x3010')
--
Changes by Alexey Smirnov :
--
nosy: +alexey-smirnov
___
Python tracker
<http://bugs.python.org/issue12970>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Alexey Smirnov :
--
nosy: +alexey-smirnov
___
Python tracker
<http://bugs.python.org/issue12971>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Alexey Shamrin :
There are many libraries in Python stdlib [1]
xml.dom
xml.dom.minidom
xml.dom.pulldom
xml.sax
xml.etree
Tutorial mentions xml.dom and xml.sax. [2]
In my experience xml.etree is the best library to quickly load some xml and
mess with it. It would be nice
Changes by Alexey Smirnov :
--
nosy: +alexey-smirnov
___
Python tracker
<http://bugs.python.org/issue12251>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexey Smirnov added the comment:
FreeBSD 8+ also supports O_CLOEXEC in open().
--
___
Python tracker
<http://bugs.python.org/issue12105>
___
___
Python-bug
New submission from Alexey Luchko :
OrderedDict.viewitems() is expected to preserve item order like items() do
>>> from collections import OrderedDict
>>> d = OrderedDict([(1, 2), ("a", "b")])
>>> d.items()
[(1, 2), ('a', 'b&#
New submission from Alexey Radkov :
The following excerpt will show the issue:
$ python
Python 2.7 (r27:82500, Sep 16 2010, 18:02:00)
[GCC 4.5.1 20100907 (Red Hat 4.5.1-3)] on linux2
Type "help", "copyright", "credits" or "license" for more inform
Changes by Alexey Smirnov :
--
nosy: +alexey-smirnov
___
Python tracker
<http://bugs.python.org/issue12105>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Alexey Luchko :
Interactive python -u produces syntax error in win2k:
> python -u
Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more inf
Alexey Luchko added the comment:
I reported the issue just because I didn't find it is already known.
I don't think it is worth backporting.
--
___
Python tracker
<http://bugs.python.o
New submission from Alexey Shamrin <[EMAIL PROTECTED]>:
In the process of trying to use optparse with russian messages, I found
several problems with gettext and unicode handling:
1. optparse.OptionParser.error function doesn't work with unicode argument
2. optparse doesn't wor
Alexey Shamrin <[EMAIL PROTECTED]> added the comment:
I've also attached a patch that fixes all these issues and also allows
the word "error" to be translated with gettext.
Regarding the use of `locale.getpreferredencoding` instead of
`sys.getdefaultencoding`. On my system
Alexey Shamrin <[EMAIL PROTECTED]> added the comment:
sampablokuper, I don't think your problem is relevant to this issue. In
addition to encoding declaration you should use unicode strings: u"your
non-ASCII text". Or wait for Python 3.0, where strings will
Alexey Borzenkov <[EMAIL PROTECTED]> added the comment:
Martin, I cleared the flag bit because filename was changed in-place, to
mark that filename does not need further processing. This was primarily
compatibility concern, to accommodate for situations where users try to
do such decod
New submission from Alexey Borzenkov <[EMAIL PROTECTED]>:
When building python 2.6 with Py_NO_ENABLE_SHARED compilation fails on
PC/getpathp.c, because it uses PyWin_DLLVersionString and
PyWin_DLLhModule unconditionally, which are implemented in PC/dl_nt.c
only when Py_ENABLE_SHARED is d
Changes by Alexey Borzenkov <[EMAIL PROTECTED]>:
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4494>
___
__
Alexey Izbyshev added the comment:
In short: both this bug report and [1] are invalid.
The reason why doing syscall(SYS_vfork) is illegal is explained by Florian
Weimer in [2]:
>The syscall function in glibc does not protect the on-stack return address
>against overwriting, so it ca
Alexey Izbyshev added the comment:
> As for glibc specifics, I'm mostly thinking of the calls we do in the child.
> According to the "Standard Description (POSIX.1)" calls to anything other
> than `_exit()` or `exec*()` are not allowed. But the longer "Linux
&
Alexey Izbyshev added the comment:
The preceding comment is wrong, see discussion in #47245 and
https://bugzilla.kernel.org/show_bug.cgi?id=215813#c14 for explanation of why
that bug report is irrelevant for CPython.
--
___
Python tracker
<ht
Alexey Izbyshev added the comment:
> 3. We have to fix error-path in order not to change heap state (contents and
> allocations), possibly do not touch locks. During vfork() child execution -
> the only parent THREAD (not the process) is blocked. For example, it's not
> all
New submission from Alexey Izbyshev :
After #40422 _Py_closerange() assumes that close_range() closes all file
descriptors even if it returns an error (other than ENOSYS):
if (close_range(first, last, 0) == 0 || errno != ENOSYS) {
/* Any errors encountered while closing file
Change by Alexey Izbyshev :
--
keywords: +patch
pull_requests: +30443
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/32418
___
Python tracker
<https://bugs.python.org/issu
Alexey Izbyshev added the comment:
> It's been years now and that hasn't happened, even with more recent flag
> additions. I think it's safe to say it won't, and such a fallback upon error
> won't put us back into a bogus pre-close_range situation where we&#
Change by Alexey Izbyshev :
--
keywords: +patch
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue47260>
___
___
Python-bugs-list mai
Change by Alexey Izbyshev :
--
pull_requests: +16379
pull_request: https://github.com/python/cpython/pull/5812
___
Python tracker
<https://bugs.python.org/issue34
Alexey Volkov added the comment:
>Why not just dismiss older queue entries during a normal get() operation? Or
>just use a plain deque with access guarded by a lock.
You do not know whether the item needs to be removed until you see it. And to
see it you need to get it. And if you
Alexey Izbyshev added the comment:
As far as I understand, commit [1] explicitly prevents CPython from running on
Windows 7, and it's included into 3.9. So it seems to be too late to complain,
despite that, according to Wikipedia, more than 15% of all Windows PCs are
still running Wind
Alexey Izbyshev added the comment:
> If Win8-only calls are not used, then presumably it should still build and
> run on Windows 7, presumably with the flag flipped back to Win7. And if there
> are Win8-only calls used and the flag is set to Win7+, I assume that the MSVC
> c
Alexey Izbyshev added the comment:
> If we had a dedicated maintainer who was supporting Win7 and making releases
> for it, then we (i.e. they) could support it. But then, there's nothing to
> stop someone doing that already, and even to stop them charging money for it
> if
Change by Alexey Namyotkin :
--
pull_requests: +24786
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/26152
___
Python tracker
<https://bugs.python.org/issu
Alexey Namyotkin added the comment:
Thanks, Terry. I signed it.
--
___
Python tracker
<https://bugs.python.org/issue24964>
___
___
Python-bugs-list mailin
New submission from Alexey Izbyshev :
In PC/getpathp.c CPython uses buffers with length MAXPATHLEN+1, which is 257 on
Windows[1]. On Windows 7, where PathCch* functions are not available, CPython
<= 3.8 fallbacks to PathCombineW()/PathCanonicalizeW()[2]. Those functions
assume that
Alexey Izbyshev added the comment:
> As a concrete example, we have a (non-Python) build system and task runner
> that orchestrates many tasks to run in parallel. Some of those tasks end up
> invoking Python scripts that use subprocess.run() to run other programs. Our
>
New submission from Alexey Burdin :
>>> x=[2,3]
>>> [f(x) for f in [(lambda a:a[i]) for i in [0,1]]]
[3, 3]
>>> [f(x) for f in [lambda a:a[0],lambda a:a[1]]]
[2, 3]
--
components: Interpreter Core
messages: 357586
nosy: Alexey Burdin
priority: normal
severity
Alexey Burdin added the comment:
x=[2,3]
[f(x) for f in [(lambda a:a[i]) for i in [0,1]]]
#the expected output is [2,3] but actual is [3,3]
[f(x) for f in [lambda a:a[0],lambda a:a[1]]]
#results [2,3] normally
--
___
Python tracker
<ht
Alexey Volkov added the comment:
This is also an issue even for non-interactive scenarios:
When doing `python -c ''` inspect.getsource does not work and there
are no stack traces.
Perhaps this case will be easier to fix?
--
nosy
New submission from Alexey Izbyshev :
> python тест.pyc
python: Can't reopen .pyc file
The issue is caused by _Py_fopen() being used as though it can deal with paths
encoded in FS-default encoding (UTF-8 by default on Windows), but in fact it's
just a simple wrapper around fopen
New submission from Alexey Izbyshev :
Before addition of audit hooks in 3.8, _Py_fopen() and _Py_wfopen() were simple
wrappers around corresponding C runtime functions. They didn't require GIL,
reported errors via errno and could be safely called during early interpreter
initializ
Alexey Izbyshev added the comment:
Thanks, Eryk, for catching the dup, I missed it somehow.
@ZackerySpytz: do you plan to proceed with your PR? If not, I can pick it up --
this issue broke the software I develop after upgrade to 3.8.
I filed issue 42569 to hopefully clarify the status of
Alexey Izbyshev added the comment:
Thanks for the patch, Victor, it looks good.
Just so it doesn't get lost: the problem with the contract of
PyErr_ProgramText() which I mentioned in my dup 42568 is still there.
--
___
Python tracker
&
Alexey Izbyshev added the comment:
> It seems like PyErr_ProgramText() is no longer used in Python.
Isn't it a part of the public API? I can't find it in the docs, but it seems to
be declared in the public header.
--
___
Python tr
Alexey Izbyshev added the comment:
> To implement PEP 446: create non-inheritable file descriptors.
Yes, I understand that was the original role. But currently there is no easy
way to deal with errors from the helpers because of exception vs. errno
conundrum. Maybe they should be split
Alexey Izbyshev added the comment:
> So it should be, "if they fail and you're in a context where exceptions are
> allowed, raise an exception" (which will chain back to the one raised from an
> audit hook".
What exception should be raised if _Py_fopen() fails (
Change by Alexey Izbyshev :
--
components: +Library (Lib)
nosy: +davin, pitrou
versions: -Python 3.6
___
Python tracker
<https://bugs.python.org/issue42
Alexey Izbyshev added the comment:
Thanks for the fix and backports!
--
resolution: fixed ->
stage: resolved -> patch review
status: closed -> open
versions: +Python 3.7
___
Python tracker
<https://bugs.python.or
Change by Alexey Izbyshev :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: -Python 3.7
___
Python tracker
<https://bugs.python.or
Alexey Izbyshev added the comment:
Yes, despite that MSVCRT knows the type of the file descriptor because it calls
GetFileType() on its creation, it doesn't check it in lseek() implementation
and simply calls SetFilePointer(), which spuriously succeeds for pipes. MSDN
says the follow
Alexey Izbyshev added the comment:
Great approach :)
--
___
Python tracker
<https://bugs.python.org/issue42569>
___
___
Python-bugs-list mailing list
Unsub
New submission from Alexey Izbyshev :
On POSIX-conforming systems, O_APPEND flag for open() must ensure that no
intervening file modification occurs between changing the file offset and the
write operation[1]. In effect, two processes that independently opened the same
file with O_APPEND
Change by Alexey Izbyshev :
--
keywords: +patch
pull_requests: +22575
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/23712
___
Python tracker
<https://bugs.python.org/issu
Alexey Izbyshev added the comment:
This bug would have been caught at compile time if `_Py_Gid_Converter()` used
`gid_t *` instead of `void *`. I couldn't find any call sites where `void *`
would be needed, so probably `_Py_Gid_Converter()` should be fixed too (in a
separate PR/issue?)
Alexey Izbyshev added the comment:
> I've been struggling to understand today why a simple file redirection
> couldn't work properly today (encoding issues)
The core issue is that "working properly" is not defined in general when we're
talking about piping
Alexey Izbyshev added the comment:
> Using close_fds=False, subprocess can use posix_spawn() which is safer and
> faster than fork+exec. For example, on Linux, the glibc implements it as a
> function using vfork which is faster than fork if the parent allocated a lot
> of memo
Change by Alexey Izbyshev :
--
nosy: +izbyshev
___
Python tracker
<https://bugs.python.org/issue38435>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Alexey Izbyshev :
--
nosy: +izbyshev
___
Python tracker
<https://bugs.python.org/issue42736>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Alexey Izbyshev :
--
components: +Library (Lib)
nosy: +vstinner
versions: -Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue42
Alexey Izbyshev added the comment:
I've encountered this issue too. My use case was a 32-bit Python on a 64-bit
CentOS system, and my understanding of the issue was that 64-bit libgcc_s is
somehow counted as a "provider" of libgcc_s for 32-bit libc by the package
manager, so
Change by Alexey Izbyshev :
--
keywords: +patch
pull_requests: +23063
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24241
___
Python tracker
<https://bugs.python.org/issu
Alexey Izbyshev added the comment:
I've made a PR to remove most calls to pthread_exit().
@xxm: could you test it in your environment?
--
___
Python tracker
<https://bugs.python.org/is
Alexey Izbyshev added the comment:
Could anybody provide their thoughts on this RFE? Thanks.
--
___
Python tracker
<https://bugs.python.org/issue42606>
___
___
Alexey Izbyshev added the comment:
> It's possible to query the granted access of a kernel handle via
> NtQueryObject: ObjectBasicInformation
Ah, thanks for the info. But it wouldn't help for option (1) that I had in mind
because open() and os.open() currently set only msvcr
Alexey Izbyshev added the comment:
Thank you for testing. I've added a NEWS entry to the PR, so it's ready for
review by the core devs.
Note that PyThread_exit_thread() can still be called by daemon threads if they
try to take the GIL after Py_Finalize(), and also via C
Change by Alexey Izbyshev :
--
nosy: +izbyshev
___
Python tracker
<https://bugs.python.org/issue42969>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexey Izbyshev added the comment:
> I don't know what you mean by default access rights.
I meant the access rights of the handle created by _wopen(). In my PR I
basically assume that _wopen() uses GENERIC_READ/GENERIC_WRITE access rights,
but _wopen() doesn't have a contractu
Alexey Izbyshev added the comment:
> FYI, here are the access rights applicable to files
Thanks, I checked that mapping in headers when I was writing
_Py_wopen_noraise() as well. But I've found a catch via ProcessHacker:
CreateFile() with GENERIC_WRITE (or FILE_GENERIC_WRITE) addi
Alexey Izbyshev added the comment:
> I think truncation via TRUNCATE_EXISTING (O_TRUNC, with O_WRONLY or O_RDWR)
> or overwriting with CREATE_ALWAYS (O_CREAT | O_TRUNC) is at least tolerable
> because the caller doesn't care about the existing data.
Yes, I had a thought th
Alexey Izbyshev added the comment:
I would suggest to start digging from the following piece of code in
`maybe_pyc_file()` (Python/pythonrun.c):
int ispyc = 0;
if (ftell(fp) == 0) {
if (fread(buf, 1, 2, fp) == 2 &&
((unsigned int)buf[1]<
Alexey Izbyshev added the comment:
> Ideally, the error would say:
> FileNotFoundError: ./demo: /usr/bin/hugo: bad interpreter: No such file or
> directory
The kernel simply returns ENOENT on an attempt to execve() a file with
non-existing hash-bang interpreter. The same occ
Alexey Izbyshev added the comment:
> FileNotFoundError: [Errno 2] No such file or directory: Either './demo' or
> the interpreter of './demo' not found.
This doesn't sound good to me because a very probable and a very improbable
reasons are combined together w
Alexey Izbyshev added the comment:
> IMO the fix is simple: only create OSError from the errno, never pass a
> filename.
This will remove a normally helpful piece of the error message in exchange to
being marginally less confusing in a rare case of non-existing interpreter (the
use
Alexey Izbyshev added the comment:
How do you propose to approach documentation of such behavior? The underlying
cause is the ambiguity of ENOENT error code from execve() returned by the
kernel, so it applies to all places where Python can call execve(), including
os.posixspawn(), os.execve
Alexey Izbyshev added the comment:
I generally agree, but getting a good, short error message seems to be the hard
part here. I previously complained[1] about the following proposal by @hroncok:
FileNotFoundError: [Errno 2] No such file or directory: Either './demo' or the
inte
Change by Alexey Izbyshev :
--
nosy: +gregory.p.smith
___
Python tracker
<https://bugs.python.org/issue43308>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexey Volkov added the comment:
>For Queue, I'm not sure I've ever seen any use case for peek. What do you
>have in mind?
I want to examine the first (oldest) element in queue and remove it if it's too
old.
The queue should not be modified unless the olde
Alexey Izbyshev added the comment:
I'd really like to get this merged eventually because vfork()-based solution is
fundamentally more generic than posix_spawn(). Apart from having no issue with
close_fds=True, it will also continue to allow subprocess to add any process
context t
New submission from Alexey Burdin :
```
answers_field_order=sorted(
set(j for i in data['items'] for j in i),
key=cmp_to_key(lambda x,y:(
-1 if (x,y) in answer_order
else (0 if x==y else 1)))
)
```
when the cursor is placed in line 5 col 31 (betwe
Change by Alexey Namyotkin :
--
nosy: +alexey.namyotkin
___
Python tracker
<https://bugs.python.org/issue7291>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexey Namyotkin added the comment:
It has been 5 years, now the urllib3 is actively used, but it also inherited
this problem: if no authentication data has been received, then the method
_tunnel raises an exception OSError that does not contain response headers.
Accordingly, this exception
Alexey Izbyshev added the comment:
Well, much later than promised, but I'm picking it up. Since in the meantime
support for setting uid/gid/groups was merged, and I'm aware about potential
issues with calling corresponding C library functions in a vfork()-child, I
asked a questi
Alexey Izbyshev added the comment:
I've updated my PR.
* After a discussion with Alexander Monakov (a GCC developer), moved vfork()
into a small function to isolate it from both subprocess_fork_exec() and
child_exec(). This appears to be the best strategy to avoid -Wclobbered
Change by Alexey Izbyshev :
--
resolution: -> not a bug
___
Python tracker
<https://bugs.python.org/issue36034>
___
___
Python-bugs-list mailing list
Un
Change by Alexey Izbyshev :
--
pull_requests: +21862
pull_request: https://github.com/python/cpython/pull/22944
___
Python tracker
<https://bugs.python.org/issue35
Alexey Izbyshev added the comment:
> Thank you for taking this on! I'm calling it fixed for now as the buildbots
> are looking happy with it. If issues with it arise we can address them.
Thank you for reviewing and merging!
Using POSIX_CALL for pthread_sigmask() is incorre
Alexey Izbyshev added the comment:
> regarding excluding the setsid() case: I was being conservative as I couldn't
> find a reference of what was and wasn't allowed after vfork.
Yes, there is no list of functions allowed after vfork(), except for the
conservative POSIX.1
Alexey Izbyshev added the comment:
@ronaldoussoren
> I'd prefer to not use vfork on macOS. For one I don't particularly trust that
> vfork would work reliably when using higher level APIs, but more importantly
> posix_spawn on macOS has some options that are hard to ac
New submission from Alexey Izbyshev :
The following test demonstrates the leak:
```
import subprocess
cwd = 'x' * 10**6
for __ in range(100):
try:
subprocess.call(['/xxx'], cwd=cwd, user=2**64)
except OverflowError:
pass
from resource impo
Change by Alexey Izbyshev :
--
keywords: +patch
pull_requests: +21882
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22966
___
Python tracker
<https://bugs.python.org/issu
1 - 100 of 470 matches
Mail list logo
