Ian Cordasco added the comment:
So I see the argument on both sides of this discussion. Having those optional
arguments for all the functions seems like an obvious blocker. If a submodule
is a blocker, what if we provide a context-manager to signal this?
--
nosy: +icordasc
Ian Cordasco added the comment:
Why did you remove Python 3.3? It's still affected by this behaviour.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Ian Cordasco:
In trying to add support for multiprocessing on Windows in Flake8, I found that
the behaviour of the module is significantly different than on Unix. If you
have a class that has class-level attributes on Unix, and you change them, put
the class into a Queue
Changes by Ian Cordasco <graffatcolmin...@gmail.com>:
--
nosy: +icordasc
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27568>
___
Changes by Ian Cordasco graffatcolmin...@gmail.com:
--
nosy: +icordasc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24667
___
___
Python-bugs
Ian Cordasco added the comment:
Also I'm marking this as affecting 3.3, 3.4, and 3.5. I haven't tested against
3.5, but it definitely fails on 3.4. I hope to be able to test against 3.5.0b2
tonight
--
versions: +Python 3.3, Python 3.4, Python 3.5
Ian Cordasco added the comment:
FWIW, the proper section to reference now is 3.2 in RFC 7230
(https://tools.ietf.org/html/rfc7230#section-3.2)
--
nosy: +icordasc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24363
Changes by Ian Cordasco graffatcolmin...@gmail.com:
--
nosy: +icordasc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24107
___
___
Python-bugs
Changes by Ian Cordasco graffatcolmin...@gmail.com:
--
nosy: +icordasc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23989
___
___
Python-bugs
Changes by Ian Cordasco graffatcolmin...@gmail.com:
--
nosy: +icordasc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23794
___
___
Python-bugs
Changes by Ian Cordasco graffatcolmin...@gmail.com:
--
nosy: +Lukasa
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23794
___
___
Python-bugs-list
Ian Cordasco added the comment:
So it seems like
https://rt.openssl.org/Ticket/Display.html?user=guestpass=guestid=3621
includes a fix that we may be able to update Python to use (safely) by default.
If we don't then this will continue to be an issue.
Other references:
- https
Ian Cordasco added the comment:
It's clearly no longer acceptable to include RC4 when the IETF has felt it
necessary to publish an RFC prohibiting its usage.
--
nosy: +icordasc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Ian Cordasco added the comment:
Keep in mind, this could also be a problem with NetBSD's distribution of python.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23155
Changes by Ian Cordasco graffatcolmin...@gmail.com:
--
nosy: +icordasc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23155
___
___
Python-bugs
Ian Cordasco added the comment:
This behaviour is allowed by the RFC but not encouraged. There's a difference
between MUST, SHOULD, and MAY
Sending this pre-emptively could well cause unexpected errors for users.
Changing the default even in 3.5 will make writing compatible code difficult
Changes by Ian Cordasco graffatcolmin...@gmail.com:
--
nosy: +icordasc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19494
___
___
Python-bugs
Ian Cordasco added the comment:
However, one sticking point is whether that optimization may also have
adverse effects in terms of security (since we would always be sending auth
headers, even when the server doesn't ask for it...).
Antoine's concern has always been a concern of mine
Changes by Ian Cordasco graffatcolmin...@gmail.com:
--
nosy: +icordasc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21039
___
___
Python-bugs
Changes by Ian Cordasco graffatcolmin...@gmail.com:
--
nosy: +icordasc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3566
___
___
Python-bugs-list
Changes by Ian Cordasco graffatcolmin...@gmail.com:
--
nosy: +icordasc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21308
___
___
Python-bugs
Changes by Ian Cordasco graffatcolmin...@gmail.com:
--
nosy: +icordasc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17849
___
___
Python-bugs
Changes by Ian Cordasco graffatcolmin...@gmail.com:
--
nosy: +icordasc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10721
___
___
Python-bugs
Ian Cordasco added the comment:
Bumping this once more.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10510
___
___
Python-bugs-list mailing
Ian Cordasco added the comment:
Per discussion on twitter
(https://twitter.com/merwok_/status/468518605135835136) I'm bumping this to
make sure it's merged.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10510
Changes by Ian Cordasco graffatcolmin...@gmail.com:
--
nosy: +icordasc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21540
___
___
Python-bugs
Ian Cordasco added the comment:
I missed the fact that the user gave me the information from sys.version:
https://stackoverflow.com/questions/16545027/ironpython-error-in-url-request?noredirect=1#comment23847257_16545027
I'll throw together a failing test with this and run it against 2.7
Ian Cordasco added the comment:
I've attached a patch that should fix this issue. Please review and let me know
if changes are necessary.
--
keywords: +patch
Added file: http://bugs.python.org/file35067/compliant_distutils.patch
___
Python tracker
Changes by Ian Cordasco graffatcolmin...@gmail.com:
--
nosy: +icordasc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10510
___
___
Python-bugs
Changes by Ian Cordasco graffatcolmin...@gmail.com:
--
nosy: +icordasc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19514
___
___
Python-bugs
New submission from Ian Cordasco:
Stemming from a StackOverflow question[1] and a conversation with Marc-Andre
Lemburg via email, I'm filing this issue without any easy way of confirming it
myself.
It seems that the logic in platform.python_implementation() has been obsoleted
by a change
Changes by Ian Cordasco graffatcolmin...@gmail.com:
--
nosy: +icordasc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12458
___
___
Python-bugs
Ian Cordasco added the comment:
Éric's suggestion is also implemented in python-requests if I remember
correctly. It allows for user-specified PEM files and tries to find the
operating system bundle. This would be a wonderful inclusion in the standard
library.
--
nosy: +icordasc
Changes by Ian Cordasco graffatcolmin...@gmail.com:
--
nosy: +icordasc, larry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12779
___
___
Python
Changes by Ian Cordasco graffatcolmin...@gmail.com:
--
nosy: +icordasc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6761
___
___
Python-bugs-list
Ian Cordasco added the comment:
As a further note, on python 2.6, I just touched a file called time.py, and in
the interpreter imported subprocess. It didn't hang because the file was empty
but it did generate a pyc file. This is almost certainly the root of your
problem. I doubt
Ian Cordasco added the comment:
Could you give us the contents of your time.py file? I wonder if there's
something in that file that is causing the import to hang. It's the only reason
I can think of as to why the time.pyc file shows up.
Also, if you want to check before-hand, make a new
Ian Cordasco added the comment:
Dave, at some point during the import of subprocess the time module is
apparently imported. Because of how imports work, it is importing your local
copy instead of the standard library version.
I would wager money that if you ran time python time.py (on your
Ian Cordasco added the comment:
Was this already taken care of?
http://docs.python.org/2/library/thread.html?highlight=thread.lock#thread.lock.acquire
and
http://docs.python.org/3.3/library/_thread.html?highlight=thread.lock#_thread.lock.acquire
don't make any mention of returning None
Ian Cordasco added the comment:
Thanks. I couldn't find it in the source but I just found
Modules/_threadmodule.c
I tested the method from the interpreter to confirm the changes I was making to
the docstring. Attached is a diff that covers the change.
--
Added file: http
40 matches
Mail list logo
