New submission from Dmitry :
We use the embedded Python in a multiscript environment. For example, VBS can
execute Python code and vice versa.
For that purpose we use a global context which is common for all running
scripts (Python, VBS etc.) and control access to variables in that context
Change by Dmitry :
--
keywords: +patch
pull_requests: +28359
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/30141
___
Python tracker
<https://bugs.python.org/issu
New submission from Dmitry :
All base64 decoding methods fail to decode a valid base64 string, throwing
'incorrect padding' regardless of the string padding.
Here's an example:
>>> base64.urlsafe_b64decode('AQAAQDhAAMAAQthJDczODFmZDM2LTNiOTYtN
Dmitry added the comment:
It doesn’t matter how many “=“ characters are appended - it’s always throwing
the same exception :(
--
___
Python tracker
<https://bugs.python.org/issue33
Dmitry added the comment:
Apologies: apparently this particular string was given with one character
missing in the beginning - should be
"AAQAAQDhAAMAAQthJDczODFmZDM2LTNiOTYtNDVmYS04MjQ2LWRkYzJkMmViYjQ2YQ".
In this case, the problem is the exception itself: i
Dmitry added the comment:
Ideally there needs to be an option to ignore non-fatal errors. Indeed, pretty
much any string should be base64-decodeable. Take a look at Perl's MIME::Base64
- it can decode pretty much any random string (so long as it only contains
valid base64 chara
Change by Dmitry :
--
title: base64 throws 'incorrect padding' exception even though the string
length is a multiple of 4 -> base64 throws 'incorrect padding' exception when
the issue is NOT with the padding
___
Dmitry added the comment:
I think something like “invalid length” message does make more sense in this
case than the misleading “incorrect padding”.
It would also be great if there was a way to force it to try its best at
decoding the string
Dmitry added the comment:
@taleinat - yes, that does look much better!
--
___
Python tracker
<https://bugs.python.org/issue33770>
___
___
Python-bugs-list mailin
New submission from Dmitry:
I launch python3 on MacOS X Maverics and do the following things:
a = '12345'
a[:-0]
And the interpreter (application python3) crashes with sigfault. Everything is
OK with python2 on this computer (the same code returnes '') and with the same
New submission from Dmitry :
Synopsys:
zimport not able to import a module from zipfile if zipfile contains
comment.
Versions:
This is Zip 2.32 (June 19th 2006), by Info-ZIP
Python 2.5.2 or 2.6.2
Steps to reproduce:
create a module, create an app that imports this module.
zip the module, make
Dmitry added the comment:
I'm talking about internal zimport function (see attached testcase):
i.e.
import sys;
sys.path.insert(0,'test.zip');
import test
test.testme()
doesn't work if test.zip contains comment.
--
___
P
New submission from Dmitry:
python fails to run zipapp when zip contains comments
when zip archive downloaded from github it contains tip hash in comment.
Python 3.5.1 (v3.5.1:37a07cee5969, Dec 6 2015, 01:38:48) [MSC v.1900 32 bit
(Intel)] on win32
example:
```
import zipfile
if __name__
New submission from dmitry-bychkov :
Currently, documentation for QueueListener
(https://docs.python.org/3/library/logging.handlers.html#queuelistener) says:
"""
supports receiving logging messages from a queue, such as those implemented in
the queue or multiprocessing modu
New submission from dmitry-bychkov :
Hello!
If you use multiprocessing logger with logging.handlers.QueueHandler it will
deadlock on first attempt at logging.
First attempt will initialize queue's background thread, which uses
multiprocessing logger itself which will result in something
Dmitry Marakasov added the comment:
> Is device number -1 used in any context (for example as "unknown device
> number")?
Yes, there's NODEV macro in both Linux and FreeBSD which expands to ((dev_t)-1).
--
___
P
Changes by dmitry be :
--
nosy: +Dmitry.Beransky
___
Python tracker
<http://bugs.python.org/issue13323>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Dmitry Balabanov :
In Europe/Moscow timezone:
>> import time
>> time.daylight
1
>>> time.timezone
-10800
But if compile and run attached program result would be:
timezone: -14400, daylight: 0
Daylight is not applicable in Europe/Moscow timezone from thi
Dmitry Simonov added the comment:
Quote:
==
Notes
Note that mailservers have a 990-character limit on each line contained within
an email message. If an email message is sent that contains lines longer than
990-characters, those lines will be subdivided by additional line
Changes by Dmitry Chichkov :
Added file: http://bugs.python.org/file18515/dc.dict.bench.0.02.py
___
Python tracker
<http://bugs.python.org/issue9520>
___
___
Python-bug
Dmitry Chichkov added the comment:
Yes, it looks like you are right. And while there is some slight performance
degradation, at least nothing drastic is happening up to 30M keys. Using your
modified test:
1000 words ( 961 keys), 3609555 words/s, 19239926 lookups/s, 51
bytes/key
Dmitry Jemerov added the comment:
I've also run into this problem after upgrading to Python 2.6.6. My code, which
uses the same HTTPBasicAuthHandler instance for many requests to the same
server, worked correctly with Python 2.6.2 and broke with 2.6.6. It would be
great if zenyatta
New submission from Dmitry Dvoinikov :
If you request Event.wait(x), the call consistently returns in less than x
seconds.
Sample:
-
from threading import Event
from time import time
e = Event()
before = time()
e.wait(0.1)
after = time
Dmitry Dvoinikov added the comment:
You are right, sorry. It's Windows XP Prof, Python 3.2a2.
The differences in OS may be the cause, but the problem doesn't appear in 3.1
on the same machine.
--
___
Python tracker
<http://bu
New submission from Dmitry Negius :
Nested "while" cycles does not work. This make impossible to write a class of
programs with nested while cycles.
--
components: Interpreter Core
files: bug.py
messages: 129506
nosy: negius
priority: normal
severity: normal
status: open
tit
New submission from Dmitry Groshev :
Here is a console output:
si14@si14-work:~/repos/monitoring/root$ python2.7 server.py
127.0.0.1 - - [2011-01-28 12:29:30] "GET /update HTTP/1.1" 200 320 "-"
"Python-urllib/2.7"
{"seenby":[1],"received":12
Dmitry Groshev added the comment:
I should also say that this bug appears at first time, but it doesn't make it
less scary. The packet that crashed python was the same as the one shown and
I've already used this tiny "server" for a day or two without modifications, so
Dmitry Groshev added the comment:
Ok, I've played with this some more and got some more segmenation faults. It
looks like a gevent problem, but I think that python shouldn't completely fall
so easy. Here is more traces:
si14@si14-work:~/repos/monitoring/root$ python2.7 server.py
Dmitry Groshev added the comment:
I've changed gevent.wsgi server to gevent.pywsgi and it works as expected. Now
I switched it back to gevent.wsgi and it doesn't crash too! That's strange, but
I understand that you can't fix it without normal backtrace. I'm sor
New submission from Dmitry Dvoinikov <[EMAIL PROTECTED]>:
This quote from base64.py:
---
bytes_types = (bytes, bytearray) # Types acceptable as binary data
...
def encodestring(s):
"""Encode a string into multiple lines of base-64 data.
Argument and r
New submission from Dmitry Dvoinikov <[EMAIL PROTECTED]>:
In xmlrpc.client:1204:
---
headers = {}
if extra_headers:
for key, val in extra_headers:
header[key] = val
---
shouldn't it read
---
headers[key] = val
^
---
?
Otherwise it bails out with
--
Dmitry Dvoinikov <[EMAIL PROTECTED]> added the comment:
> I think it probably is correct to NOT accept a string
I agree.
> it should be renamed to encodestring
Huh ? It is already called that :) IMO it should be renamed to
encodebytes or simply encode if the module is only (or mos
New submission from Dmitry Vasiliev <[EMAIL PROTECTED]>:
The following commands fail badly:
>>> from nntplib import NNTP
>>> s = NNTP("free-text.usenetserver.com")
Traceback (most recent call last):
File "", line 1, in
File "/py3k/Lib/nn
Dmitry Vasiliev <[EMAIL PROTECTED]> added the comment:
I've attached the patch which adds encoding parameter to the NNTP class.
--
keywords: +patch
Added file: http://bugs.python.org/file11292/nntplib.patch
___
Python tracker <[E
New submission from Dmitry Vasiliev <[EMAIL PROTECTED]>:
Simple example:
>>> from telnetlib import Telnet
>>> t = Telnet("google.com", 80)
>>> t.write("GET / HTTP/1.1\r\n")
Traceback (most recent call last):
File "",
Dmitry Vasiliev <[EMAIL PROTECTED]> added the comment:
I think only bytes need to be allowed for write() and read*() because of
low-level nature of Telnet. I can create a patch later.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Dmitry Vasiliev <[EMAIL PROTECTED]>:
Example:
>>> from poplib import POP3
>>> p = POP3("localhost")
>>> p.user("user")
Traceback (most recent call last):
File "", line 1, in
File "/py3k/Lib/poplib.py&qu
New submission from Dmitry Vasiliev <[EMAIL PROTECTED]>:
Example:
>>> from imaplib import IMAP4
>>> m = IMAP4("localhost")
Traceback (most recent call last):
File "", line 1, in
File "/py3k/Lib/imaplib.py", line 185, in __init__
Dmitry Vasiliev <[EMAIL PROTECTED]> added the comment:
Ah, yes.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3728>
___
___
Python-bugs
Dmitry Vasiliev <[EMAIL PROTECTED]> added the comment:
Actually RFC-977 said all characters must be in ASCII, but RFC-3977
changed default character set to UTF-8. So I think UTF-8 must be default
encoding, not Latin-1. Moreover Latin-1 can silently hide a real
encoding, for example:
Dmitry Vasiliev <[EMAIL PROTECTED]> added the comment:
If I understand it correctly there is no "character set used by server"
because every article can be in different encoding. RFC-3977 say:
"""
The character set of article bodies SHOULD be indicated in the
arti
Dmitry Vasiliev <[EMAIL PROTECTED]> added the comment:
RFC-3977 say the following about headers:
- The names of headers (e.g., "From" or "Subject") MUST be in
US-ASCII.
- Header values SHOULD use US-ASCII or an encoding based on it, such
as RFC 2047 [RFC2047],
Dmitry Vasiliev <[EMAIL PROTECTED]> added the comment:
Actually it was an optimization. PyList_Insert() was used for list and
list-derived objects.
I've attached the patch which fix the issue and for me the new code
looks even cleaner than the original code.
--
keywords:
Dmitry Vasiliev <[EMAIL PROTECTED]> added the comment:
Good idea! Don't know why I didn't use it in the very first version. :-)
New patch attached.
Added file: http://bugs.python.org/file11623/bisect2.patch
___
Python tracker <[EMAI
New submission from Dmitry Jemerov :
I'm trying to download a file from a site using HTTP authentication. I'm
subclassing FancyURLOpener, returning my credentials from the
prompt_user_passwd() method, and using opener.retrieve() to download the file.
I get the following error:
Dmitry Jemerov added the comment:
from urllib.request import *
opener = FancyURLopener()
opener.retrieve("http://username:passw...@google.com/index.html";, "index.html")
--
___
Python tracker
<http://bu
New submission from Dmitry Chichkov :
I've run into a case where pprint isn't really pretty.
import pprint
pprint.PrettyPrinter().pprint([1]*100)
Prints a lengthy column of '1'; Not pretty at all. Look:
[1,
1,
1,
1,
1,
1,
1,
1,
1,
1,
1,
1,
1,
1,
1,
1,
1
Dmitry Chichkov added the comment:
Quick, dirty and utterly incorrect patch that works for me. Includes
issue_5131.patch (defaultdict support, etc). Targets trunk (2.6), revision
77310.
--
keywords: +patch
Added file: http://bugs.python.org/file16640/issue_8228.dirty.patch
Dmitry Chichkov added the comment:
Yes. This patch is nowhere near the production level. Unfortunately it works
for me. And in the moment I don't have time to improve it further. Current
version doesn't check the item's width upfront, there is definitely room for
improvement.
Dmitry Dvoinikov added the comment:
The problem does not reproduce in 3.1.1 nor in 3.1.2
(either x86 or x64).
Antoine Pitrou пишет:
> Antoine Pitrou added the comment:
>
> What happens if you remove the call to settimeout()?
> Also, it would be nice if you could try with the
New submission from Dmitry Chichkov :
The namespace_separator parameter is hard coded in the cElementTree.XMLParser
class disallowing the option of ignoring XML Namespaces with cElementTree
library.
Here's the code example:
from xml.etree.cElementTree import iterparse
from StringIO i
Changes by Dmitry Chichkov :
--
keywords: +patch
Added file: http://bugs.python.org/file17153/issue-8583.patch
___
Python tracker
<http://bugs.python.org/issue8
Dmitry Chichkov added the comment:
And obviously iterparse can be either overridden in the local user code or
patched in the library. Here's the iterparse code/test code:
import cElementTree
from cStringIO import StringIO
class iterparse(object):
root = None
def __init__(self,
Dmitry Chichkov added the comment:
This patch does not modify the existing behavior of the library. The
namespace_separator parameter is optional. Parameter already exists in the
EXPAT library, but it is hard coded in the cElementTree.XMLParser code.
Fredrik, yes, namespaces are a
Dmitry Chichkov added the comment:
I agree that the argument name choice is poor. But it have already been made by
whoever coded the EXPAT parser which cElementTree.XMLParser wraps. So there is
not much room here.
As to 'proposed feature have to be used with great care by users'
Dmitry Chichkov added the comment:
Interestingly in precisely these applications often you don't care about
namespaces at all. Often all you need is to extract 'text' or 'name' elements
irregardless of the namespace.
--
Dmitry Dvoinikov added the comment:
Well, I'm sorry to bring this up again, but the problem persists
with Python 3.1.2 (x86, Windows XP). The difference with the
test script behaviour is that now it doesn't break every time.
Perhaps this is the reason I said the problem was gone.
In
Dmitry Dvoinikov added the comment:
Checked out and built revision 80956 of py3k against OpenSSL 0.9.8n. Here is
the banner:
Python 3.2a0 (py3k:80956, May 8 2010, 11:31:45) [MSC v.1500 32 bit (Intel)] on
win32
Now, the breaking script appears not to be breaking any more, even though I
New submission from Dmitry Dvoinikov <[EMAIL PROTECTED]>:
Stack trace information extracted with traceback.extract_stack is
incorrect in that the #-*- line causes double counting. For example:
#comment
from traceback import extract_stack
print("this is line", extract_stack()
New submission from Dmitry Dvoinikov <[EMAIL PROTECTED]>:
If a context manager is used within exception handling block, the active
exception is silenced after the context block completes and __exit__ exits.
try:
raise Exception("foo")
except:
with SomeContextManager
Dmitry Vasiliev <[EMAIL PROTECTED]> added the comment:
Oh, you need to read the comments first:
- Use of ISO-8859-1 it's a bad idea here. See msg72776 for details.
Moreover RFC-3977 explicitly say about UTF-8, so I think we need to use
UTF-8.
- Maybe set_encoding() isn't needed
Dmitry Vasiliev <[EMAIL PROTECTED]> added the comment:
The patch is good. It's exactly what I told about in msg72132.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Changes by Dmitry Dvoinikov <[EMAIL PROTECTED]>:
--
nosy: +ddvoinikov
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3890>
___
__
New submission from Dmitry Dvoinikov <[EMAIL PROTECTED]>:
If I connect a TCP socket s using regular s.connect(), then wrap it
using ssl.wrap_socket(s) and call do_handshake on the resulting SSL
socket, handshake fails in ssl.py:320 with
AttributeError: 'NoneType' object
Dmitry Dvoinikov <[EMAIL PROTECTED]> added the comment:
1.py == test.py obviously :)
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4171>
___
_
Dmitry Dvoinikov <[EMAIL PROTECTED]> added the comment:
Same thing on Python 3.0rc2:
C:\TEMP>python test.py
worked so far
Traceback (most recent call last):
File "1.py", line 23, in
test_handshake(address, False)
File "1.py", line 17, in test_handshake
New submission from Dmitry Vasiliev <[EMAIL PROTECTED]>:
The attached patch removes dependency on ctypes from uuid.uuid1() and
uuid.uuid4() functions.
--
components: Library (Lib)
files: uuid.patch
keywords: patch
messages: 76107
nosy: hdima
severity: normal
status: open
title
New submission from Dmitry Vasiliev :
It seems the wsgiref package was copied from Python 2.* without any
modifications. There are already 3 issues about that but they only
describe a part of the problem so I decided to start a new one. The
issues was:
http://bugs.python.org/issue3348
http
Dmitry Vasiliev added the comment:
Antoine Pitrou wrote:
> FYI, instead of trying to do exhaustive type checking in _check_type(),
> you can just rely on duck typing and catch the TypeError:
Good point! I'll update the patch soon.
___
Python tra
Dmitry Vasiliev added the comment:
Antoine Pitrou wrote:
>> If you want to change to using bytes, you're going to have to take it
>> to the Web-SIG and hash out a revision to PEP 333, which at the moment
>> requires the use of strings, period.
>
> What was cal
Dmitry Vasiliev added the comment:
New version of the patch:
- Now only Unicode strings are allowed as status and headers because
allowing bytes leads to big changes in wsgiref.validate and
wsgiref.handlers;
--
versions: -Python 3.1
Added file: http://bugs.python.org/file12429
Dmitry Vasiliev added the comment:
OK, I've attached PEP-333 compatible fixes for wsgiref. I think there is
only one problem remains:
- wsgiref expects io.BytesIO as input and output streams because of
http.server module. I didn't find any restrictions on data returned by
read() met
Dmitry Vasiliev added the comment:
Antoine Pitrou wrote:
> Le mardi 23 décembre 2008 à 11:15 +0000, Dmitry Vasiliev a écrit :
>> OK, I've attached PEP-333 compatible fixes for wsgiref.
>
> I may be mistaken, but it seems that your patch forces iso-8859-1
> encoding of ht
Changes by Dmitry Vasiliev :
Removed file: http://bugs.python.org/file12423/wsgiref.patch
___
Python tracker
<http://bugs.python.org/issue4718>
___
___
Python-bugs-list m
Changes by Dmitry Vasiliev :
Removed file: http://bugs.python.org/file12429/wsgiref2.patch
___
Python tracker
<http://bugs.python.org/issue4718>
___
___
Python-bugs-list m
Changes by Dmitry Vasiliev :
Removed file: http://bugs.python.org/file12431/wsgiref_pep333.patch
___
Python tracker
<http://bugs.python.org/issue4718>
___
___
Python-bug
Dmitry Vasiliev added the comment:
Attached new WSGI 1.0+ version of the patch.
Added file: http://bugs.python.org/file12439/wsgiref.patch
___
Python tracker
<http://bugs.python.org/issue4
Dmitry Vasiliev added the comment:
Phillip J. Eby wrote:
> Graham: thanks for pointing that out; I completely forgot we already
> *had* the migration discussion on the Web-SIG! It just slipped my
> mind because I didn't have any 3.0 work on the horizon.
Good to see we came
Changes by Dmitry Vasiliev :
Removed file: http://bugs.python.org/file12439/wsgiref.patch
___
Python tracker
<http://bugs.python.org/issue4718>
___
___
Python-bugs-list m
Dmitry Vasiliev added the comment:
Attached updated version of the patch.
Added file: http://bugs.python.org/file12447/wsgiref.patch
___
Python tracker
<http://bugs.python.org/issue4
Dmitry Vasiliev added the comment:
Graham Dumpleton wrote:
> the check for number of arguments supplied to wsgi.input.read() is wrong as
> it allows for an optional argument,
> when argument is supposed to mandatory.
I think it's a good idea. I'll up
Dmitry Vasiliev added the comment:
Attached more generic version of the patch.
--
nosy: +hdima
Added file: http://bugs.python.org/file12450/io_fixes.patch
___
Python tracker
<http://bugs.python.org/issue4
Dmitry Vasiliev added the comment:
Added check for wsgi.input.read() argument.
Added file: http://bugs.python.org/file12454/wsgiref2.patch
___
Python tracker
<http://bugs.python.org/issue4
Dmitry Vasiliev added the comment:
Antoine Pitrou wrote:
> The patch looks ok to me, although the tests against mutable byte-like
> types are probably useless.
Hmm, it's strange because such tests was removed two versions ago (per
discussion with Phillip). But at the time they
Dmitry Vasiliev added the comment:
Antoine Pitrou wrote:
>> Hmm, it's strange because such tests was removed two versions ago (per
>> discussion with Phillip). But at the time they really was needed.
>
> Not a big deal anyway, let's keep them and we'll see.
Dmitry Vasiliev added the comment:
Antoine Pitrou wrote:
> Why do you say they were removed? I see code like "assert
> isinstance(value, bytes)".
Support and tests for mutable "bytearray" and "memoryview" was removed.
All subclasses of "bytes"
New submission from Dmitry Vasiliev :
Small typo about "call" Process.daemon flag. The patch attached.
--
assignee: georg.brandl
components: Documentation
files: multiprocessing.patch
keywords: patch
messages: 78516
nosy: georg.brandl, hdima
severity: normal
status: open
ti
Dmitry Vasiliev added the comment:
Graham Dumpleton wrote:
> Thus have odd situation where with Python 3.0, one could technically return
> str as iterable, with rule that would apply would be that each str returned
> would then be converted to bytes by way of latin-1 conversion
Dmitry Vasiliev added the comment:
Antoine Pitrou wrote:
> People, does this patch look ok to you?
Oh, didn't know about -bb.
The patch looks OK for me.
___
Python tracker
<http://bugs.python.or
Dmitry Vasiliev added the comment:
Antoine Pitrou wrote:
> There's another problem in that buildbot failure with the environment
> variable "NO_PROXY". We'll see if it's still there after the patch.
Strange error and it seems there is only part of the tr
Dmitry Vasiliev added the comment:
Antoine Pitrou wrote:
>> Strange error and it seems there is only part of the traceback. I've
>> already seen such "partially displayed" Python 3 traceback and error
>> actually can be in very different place.
>
> If y
Dmitry Vasiliev added the comment:
Attached patch for test_urllib, possible source of the "NO_PROXY" problem.
Added file: http://bugs.python.org/file12577/no_proxy.patch
___
Python tracker
<http://bugs.python.
Change by Dmitry Shachnev :
--
nosy: +mitya57
___
Python tracker
<https://bugs.python.org/issue5>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Dmitry Marakasov :
System: FreeBSD 12.0-RELEASE, amd64.
This simple program
from multiprocessing import Pool
from time import sleep
Pool().map(sleep, [0.01] * 10)
works fine with python 3.7, but is likely (about 20-50% probability on my 4
core box) to hang
New submission from Dmitry Marakasov :
I'm playing with adding python3.10a7 port to FreeBSD ports collection, and have
run into similar problem with building multiple third party modules (for
instance, yaml, yarl and pystemmer). Here's log from yaml:
running build_ext
cyth
Dmitry Marakasov added the comment:
> This issue is a bug in Cython, not in Python. I close it.
This is correct, thanks! The problem is gone with git master version of cython.
--
___
Python tracker
<https://bugs.python.org/issu
New submission from Dmitry Kropachev :
ThreadPoolExecutor and ProcessPoolExecutor spawn threads and processes with
default value of daemon flag, i.e. None.
In some cases it would handful to have control over daemon flag of spawned
threads and processes.
Simple 6-line fix to enable it
Change by Dmitry Kropachev :
--
keywords: +patch
pull_requests: +25107
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26511
___
Python tracker
<https://bugs.python.org/issu
Dmitry Kulazhenko added the comment:
Based on what I've read, workaround:
from functools import singledispatchmethod
def _register(self, cls, method=None):
if hasattr(cls, "__func__"):
setattr(cls, "__annotations__", cls.__func__.__
Change by Dmitry Kulazhenko :
--
nosy: +EugenePY, FFY00, Viktor Roytman, glyph, levkivskyi, lukasz.langa,
markgrandi, mental, ncoghlan, xtreak
___
Python tracker
<https://bugs.python.org/issue39
1 - 100 of 314 matches
Mail list logo