Gregory P. Smith added the comment:
It doesn't seem very abusable... Though of a server accepts enough remote
connections and uses input() and swaps out stdin after remote uses up fds
with connections... That's a lot of circumstances at once. Rare
application.
We ran into
Gregory P. Smith added the comment:
Bummer. I wish select could die. :)
On Thu, Mar 2, 2017, 1:06 PM Martin Panter wrote:
>
> Martin Panter added the comment:
>
> Be careful, some OSes have limited support for “poll”, “kqueue”, etc with
> terminals, and I ended up using “sele
Gregory P. Smith added the comment:
This came up in the language summit today when discussing twisted. .format()
is still not supported on bytes though % is in 3.5.
realistically it sounded like twisted needs to support python 3.4 for many
years so they can't rely on bytes having a .f
Changes by Gregory P. Smith :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue26083>
___
___
Python-bugs-
Changes by Gregory P. Smith :
--
assignee: -> gregory.p.smith
nosy: +gregory.p.smith
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Gregory P. Smith :
--
assignee: -> gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue26372>
___
___
Python-bugs-list mailing list
Un
Changes by Gregory P. Smith :
--
assignee: -> gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue27122>
___
___
Python-bugs-list mailing list
Un
Gregory P. Smith added the comment:
I'll take this as a documentation update for 3.5 and a feature request for
better message text in 3.6.
--
assignee: -> gregory.p.smith
nosy: +gregory.p.smith
versions: +Python 3.6
___
Python tracke
Gregory P. Smith added the comment:
+cc Christian Heimes: do the upcoming standard hash functions amenable to a
constant class attribute digest_size?
Are any of the expected future hashes variable length from a single class /
constructor function?
--
nosy: +christian.heimes
Changes by Gregory P. Smith :
--
assignee: -> gregory.p.smith
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue27164>
___
___
Python-
New submission from Gregory P. Smith:
Can you sign the Python contributor form -
https://www.python.org/psf/contrib/contrib-form/? (If you already have, just
say so.)
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.
Gregory P. Smith added the comment:
Thanks Serhiy. Given that, I suggest checking if the new tests this adds are
already covered in test_pep292.py or not to decide if we should move forward
with this patch or not.
--
___
Python tracker
<h
Changes by Gregory P. Smith :
--
assignee: gregory.p.smith ->
___
Python tracker
<http://bugs.python.org/issue27164>
___
___
Python-bugs-list mailing list
Un
Gregory P. Smith added the comment:
Capturing some notes from looking at this after Dan Sully asked me questions
about the issue during today's pycon sprints:
within multiprocessing/managers.py serve_forever():
the accepter thread is an infinite loop. i think this issue also wants to
Gregory P. Smith added the comment:
comments added to the code review.
--
___
Python tracker
<http://bugs.python.org/issue16113>
___
___
Python-bugs-list mailin
New submission from Gregory P. Smith:
The --with-lto support added in issue25702 can work with clang, but on a Linux
distribution such as ubuntu 16.04 with clang installed you get:
$ CC=clang ./configure --with-lto
...
$ make profile-opt
Error: Cannot perform PGO build because llvm-profdata
Gregory P. Smith added the comment:
I made the change to not export the Forking names on Windows or other
non-os.fork() supporting platforms in 3.6 only as it is arguably an API change,
even though the names it removes would effectively be unusable on those
platforms anyways.
the docs still
Gregory P. Smith added the comment:
the main part of this issue is done but it can't be closed until the
dependencies listed are also dealt with. un-assigning myself.
--
assignee: gregory.p.smith ->
resolution: -> fixed
___
Python tra
Gregory P. Smith added the comment:
docs updated (7b12180481da and 19d77132f38d).
working on the error message update.
--
___
Python tracker
<http://bugs.python.org/issue27
Gregory P. Smith added the comment:
It may be worth rolling back the above two commits. I'm not sure. I'd like to
see if anything else falls out of this during the beta phases.
There is a chance that some library has code similar to that found in
test_socketserver.py that defin
Changes by Gregory P. Smith :
--
resolution: -> fixed
stage: needs patch -> commit review
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Gregory P. Smith :
--
versions: -Python 3.5
___
Python tracker
<http://bugs.python.org/issue27167>
___
___
Python-bugs-list mailing list
Unsubscribe:
Gregory P. Smith added the comment:
So this is mostly done... one oddity which may warrant improvement though:
signal numbers have multiple names. ie: SIGABRT is also known as SIGIOT, etc.
This is likely to be confusing to if the error message is surfaced to the user
as most users only know
Changes by Gregory P. Smith :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue27167>
___
___
Python-bugs-
Changes by Gregory P. Smith :
--
dependencies: +zlib: OverflowError while trying to compress 2^32 bytes or more
stage: -> needs patch
___
Python tracker
<http://bugs.python.org/issu
Changes by Gregory P. Smith :
--
resolution: -> fixed
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.org/issue26372>
___
___
Gregory P. Smith added the comment:
Lukas - cc'ing you just in case this bug is related to the asyncio subprocess
race condition-ish problems you were talking about at pycon.
--
nosy: +lukasz.langa
___
Python tracker
<http://bugs.py
Gregory P. Smith added the comment:
the bot hasn't piped up with the changesets. these are the 3.5 and default
fixes:
remote: notified python-check...@python.org of incoming changeset 883cfb3e28f9
remote: notified python-check...@python.org of incoming changeset 78e81de
Changes by Gregory P. Smith :
--
stage: commit review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue26372>
___
___
Pyth
Gregory P. Smith added the comment:
Executing code in any form from untrusted sources can do arbitrary things.
If someone can corrupt .pyc data before python executes it, they are just as
likely to be able to corrupt other things leading to more direct exploits not
even requiring the CPython
Changes by Gregory P. Smith :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Gregory P. Smith added the comment:
Patch review: I see two competing solutions with differing behaviors.
Yury's raises a RuntimeError in the loop situation.
Serhiy's simply reorders the exception context to put the referred to one at
the front of the chain in the event of a loop
Changes by Gregory P. Smith :
--
stage: commit review -> patch review
___
Python tracker
<http://bugs.python.org/issue25782>
___
___
Python-bugs-list mai
Changes by Gregory P. Smith :
--
dependencies: +CPython hangs on error __context__ set to the error itself
___
Python tracker
<http://bugs.python.org/issue27
Changes by Gregory P. Smith :
--
assignee: gregory.p.smith -> ncoghlan
___
Python tracker
<http://bugs.python.org/issue27122>
___
___
Python-bugs-list mai
Gregory P. Smith added the comment:
Proposed fix based on STINNER and Nick's earlier comments and the simple
reproducer turned into a test.
Nick - your most recent comment makes me wonder if this shouldn't be doing more.
this does make both hang_bug*.py examples do something reason
Gregory P. Smith added the comment:
I think I'm with Nick on this, the re-ordering fix is the closest to the right
thing to do for 3.5 as it at least leaves all exceptions present in the chain.
As a more accurate long term fix, it would be great if we could express the
tree via tupl
Gregory P. Smith added the comment:
Fixes are in 3.5 and default:
remote: notified python-check...@python.org of incoming changeset 9ee36b74b432
remote: notified python-check...@python.org of incoming changeset 9fadeee05880
--
___
Python tracker
Gregory P. Smith added the comment:
(with a follow up change to fix the typo in the news file which the bot hasn't
seen fit to mention here yet)
i'm removing the 25782 dependency as that isn't blocking fixing this.
--
dependencies: -CPython hangs on error __context__ s
Gregory P. Smith added the comment:
(ignore that... typo in the commit log for issue27122's fix)
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/is
Changes by Gregory P. Smith :
--
nosy: -gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue27123>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Gregory P. Smith :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
type: -> behavior
___
Python tracker
<http://bugs.python
Gregory P. Smith added the comment:
FWIW at this point i'm not willing to "fix" issues in Python 2.7's subprocess
module for POSIX platforms as subprocess32 is a superior drop in alternative
without the issues.
inspecting the 2.7 code, if you are seeing a memory leak and
Gregory P. Smith added the comment:
ah, okay, that makes much more sense and is indeed a bug.
Recommendation given that most people won't be using a python 2.7 version that
has this and tons of other subprocess from a threaded process bugs fixed: Use
subprocess32 where this isn't
Gregory P. Smith added the comment:
For me the momentum on fixing these things has stalled because I no longer work
on any code that runs into this. There is a fundamental problem: You cannot
safely use threading and os.fork() in the same application per POSIX rules. So
even if the standard
Gregory P. Smith added the comment:
My intent is not to block anything. I'm Just explaining why I'm not motivated
to spend much time on this issue myself. Others are welcome to.
subprocess is not related to this issue, it has been fixed for use with threads
(in 3.2 and highe
Changes by Gregory P. Smith :
--
nosy: -gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue1621>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Gregory P. Smith :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue27664>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Gregory P. Smith :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue20215>
___
___
Python-bugs-list mailing list
Unsubscribe:
Gregory P. Smith added the comment:
TL;DR - We really need reliable tests for the exact behavior we want before
coming up with patches.
attached is a patch (-gps01) that would do the same thing as Lib/smtpd.py
does... But I'm not convinced it is a good idea.
Would forc
Changes by Gregory P. Smith :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue26750>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Gregory P. Smith :
--
resolution: -> fixed
stage: patch review -> commit review
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Gregory P. Smith :
--
nosy: -gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue10721>
___
___
Python-bugs-list mailing list
Unsubscribe:
Gregory P. Smith added the comment:
This appears to have been fixed by at least issue27130's
https://hg.python.org/cpython/rev/2192edcfea02 recent commits.
greg:cpython/build27$ ./python -c "import zlib;zlib.crc32('a'*(1<<31))"
greg:cpython/build27$ ./pyt
Gregory P. Smith added the comment:
A workaround for this on 3.5 and older versions is probably to do:
initialization:
num_q = queue.Queue()
map(num_q.put, range(max_workers))
Then schedule max_workers identical tasks:
def task():
threading.current_thread().name = '%s_%d' % (y
Gregory P. Smith added the comment:
cleaned up a bit with documentation added and submitted. thanks.
ThreadPoolExecutor threads now have a default name as well, because why not.
--
resolution: -> fixed
stage: patch review -> commit review
status: open -&g
Gregory P. Smith added the comment:
Probably just Amaury and I forgetting that existed. Amaury,
inspect.isdatadescriptor's implementation is a bit different than this change's
_is_data_descriptor. Thoughts?
--
stage: resolved ->
Changes by Gregory P. Smith :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue26526>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Gregory P. Smith :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue27574>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Gregory P. Smith :
--
nosy: +ned.deily
priority: normal -> release blocker
___
Python tracker
<http://bugs.python.org/issue27736>
___
___
Python-
Gregory P. Smith added the comment:
This is very architecture specific and focused on low level information that
you can also already get from places like /proc/cpuinfo on Linux.
Also, regardless of what capability bits a CPU exposes that has nothing to do
with what accelerations the
Changes by Gregory P. Smith :
--
stage: commit review -> resolved
___
Python tracker
<http://bugs.python.org/issue26750>
___
___
Python-bugs-list mai
Gregory P. Smith added the comment:
There are so many existing tools that already do this I don't really see why
Python needs to become yet another one. What is the value in doing this?
Just use the openssl command. "openssl sha256 myfile" Or any of the md5sum,
sha1sum and
Gregory P. Smith added the comment:
The processor capabilities vector is not the API you want.
What you want is an API to ask the ssl library about characteristics of
algorithm implementations it will be using.
Those are not the same thing.
If we want to expose processor capabilities as a
Changes by Gregory P. Smith :
--
nosy: +gregory.p.smith
priority: normal -> high
___
Python tracker
<https://bugs.python.org/issue23702>
___
___
Python-bugs-lis
Changes by Gregory P. Smith :
--
nosy: +gregory.p.smith
priority: normal -> high
versions: +Python 2.7
___
Python tracker
<https://bugs.python.org/issu
Changes by Gregory P. Smith :
--
versions: +Python 3.6 -Python 3.4
___
Python tracker
<https://bugs.python.org/issue21541>
___
___
Python-bugs-list mailin
Gregory P. Smith added the comment:
We use Modules/Setup.local to build the _ssl and _hashlib modules against our
an SSL library of our choosing at work using a Setup entry like this:
_ssl _ssl.c $(PY_CORE_CFLAGS) -DUSE_SSL -I%{SSL_ROOT}/include \
-Wl,--version-script,_ssl.lds
Gregory P. Smith added the comment:
this bug was likely introduced when i applied the telnetlib patches to use poll
to not hit the select fd limit. doh. nice catch!
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue17
Gregory P. Smith added the comment:
re-yank it. that was unintentional. less sections == better.
--
___
Python tracker
<http://bugs.python.org/issue17
Gregory P. Smith added the comment:
os.fork() is a low level system call wrapper. Anyone using it needs to deal
with flushing whatever buffers their application has before forking among many
many other things. There is a reason it lives in the os module.
It is already a dangerous system
Gregory P. Smith added the comment:
An update to libffi is needed for all maintained versions of Python.
In 2.7, we're running into the stack being misaligned in 32-bit x86 code which
is something a libffi update fixes. It is a simple patch:
http://patchwork.ozlabs.org/patch/58128/
New submission from Gregory P. Smith:
The problem: without the stack being 16-byte aligned, code generated by modern
compilers like recent gcc/g++ or clang assumed that the stack is 16 byte
aligned and uses SSE instructions in some circumstances that require this.
Without this fix, any
Gregory P. Smith added the comment:
http://bugs.python.org/issue17245 filed to track the stack alignment issue.
The only reason i set this as release blocker is to let a release manager
decide which of these two issues to proceed with for 2.7.4 and 3.2.4 (and
3.3.1
Gregory P. Smith added the comment:
yeah that looks like stdin was closed or was /dev/null.
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Gregory P. Smith added the comment:
File "/home/riley/pywikipedia/userinterfaces/terminal_interface_base.py", line
129, in input
text = getpass.getpass('')
you can't call getpass without stdin or a terminal and expect it to do
anything. your problem is in
New submission from Gregory P. Smith:
bytearray has many methods that return a *new* bytearray object rather than
applying the transformation to modify the bytearray in place. Given that one
use of bytearray's is to avoid making extra copies... There should be in-place
variants o
Gregory P. Smith added the comment:
Translate isn't a text operation. (That's the api I wanted). The others I
only lists for completeness because someone else would complain if I
hadn't. ;)
On Mar 1, 2013 12:57 PM, "Terry J. Reedy" wrote:
>
> Terry J. Reedy add
Gregory P. Smith added the comment:
Yes! 2to3 features are allowed in stable releases.
On Mar 2, 2013 5:17 AM, "Ezio Melotti" wrote:
>
> Ezio Melotti added the comment:
>
> Can this still go on 2.7/3.2/3.3?
>
> --
>
> ___
Gregory P. Smith added the comment:
looks sane and cleaner than the silly x32 hack in there, i'll take care of it.
FYI - your patch forgot to add the "unsigned char d_type;" struct member before
name. fixed and applied.
When i wrote that code I was probably assuming that st
Gregory P. Smith added the comment:
The bytes (and bytearray?) version of this should generate memoryview's instead
of new bytes objects to avoid a copy.
While not required, It'd be useful if the implementation of this pre-scanned
the data internally so that the length of the
Gregory P. Smith added the comment:
Indeed, a bytearray version would require the talked about but not implemented
due to complexity (in pep3118) support for locking a buffer from other
mutations. best concentrate on bytes then.
Do we have a memoryview equivalent for PyUnicode? If not, we
Gregory P. Smith added the comment:
The important reasons for this are memory use and cache thrashing, not just
CPU time.
--
___
Python tracker
<http://bugs.python.org/issue17
Gregory P. Smith added the comment:
The gain will be more noticeable the faster the Python implementation it is
running under is. It is going to avoid logN relloc's in just about all
implementations. That CPython is relatively slow is not a justification to
avoid adding the feature.
I
Changes by Gregory P. Smith :
--
versions: +Python 3.4 -Python 3.3
___
Python tracker
<http://bugs.python.org/issue13229>
___
___
Python-bugs-list mailin
Gregory P. Smith added the comment:
I'd like to take care of this at Python. At least for posix (someone else can
deal with the windows side if they want).
I just stumbled upon an extension module at work that someone wrote
specifically because os.listdir consumed way too much r
Gregory P. Smith added the comment:
right he has a separate issue open tracking the walkdir stuff in
issue13229. I saw it first before finding this issue which is exactly what
I wanted. :)
--
___
Python tracker
<http://bugs.python.org/issue11
Gregory P. Smith added the comment:
It'd perhaps have been better if things like memoryview were never exposed to
the user at all as a distinct type and became an internal implementation detail
behind PyBytes and PyUnicode objects (they could hold a reference to something
else or col
Changes by Gregory P. Smith :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue3329>
___
___
Python-bugs-list mailing list
Unsubscribe:
Gregory P. Smith added the comment:
If this is done, it should probably be on by default on all --with-pydebug
buildbots. Otherwise I suspect nobody will _ever_ look at its output and we
should just remove the feature all together.
Being off in the main process on the build bots would still
Gregory P. Smith added the comment:
I'd personally say don't bother with this. Let people who _need_ this use
their own C extension modules to handle all secure data as we're not in a
position to make and test any guarantees about what happens to data anywhere
within a Python
Changes by Gregory P. Smith :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue3982>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Gregory P. Smith :
--
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: imaplib.IMAP4_stream subprocess is opened unbuffered but ignores short
reads
___
Python tracker
<http://bugs.python.org/issue17
New submission from Gregory P. Smith:
imaplib.IMAP4_stream subprocess is opened unbuffered but ignores short reads
when reading the message body. Depending on timing, message body size and
kernel pipe buffer size and phase of the moon and whether you're debugging the
thing or not... I
Gregory P. Smith added the comment:
The error does not happen when running the same code under 2.7, despite the
same default bufsize=0 subprocess behavior. This is likely due to differences
in the Python 2.x old style io library when os.fdopen(fd, 'rb', bufsize) is
used vs 3.x wh
Gregory P. Smith added the comment:
Yes imaplib can be fixed pretty easily and should use buffered IO regardless.
I'm pondering if the default behavior of subprocess needs fixing as
existing python 2.x code being ported to 3 doesn't expect this changed
behavior of the PIPE file ob
Changes by Gregory P. Smith :
--
assignee: -> gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue17192>
___
___
Python-bugs-list mailing list
Un
Gregory P. Smith added the comment:
I'm taking care of this with a libffi update per #17192 and #19245. Thanks for
the upstream fix into libffi 3.0.13 alex. :)
--
nosy: +gregory.p.smith
resolution: -> duplicate
status: open -> closed
___
Changes by Gregory P. Smith :
--
superseder: -> ctypes libffi needs to align the x86 stack to 16 bytes
___
Python tracker
<http://bugs.python.org/issu
Changes by Gregory P. Smith :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue14803>
___
___
Python-bugs-list mailing list
Unsubscribe:
3101 - 3200 of 3457 matches
Mail list logo