Richard PALO added the comment:
If I also add .encode('utf-8') to filename on line 278, that seems gets over
the pathname problem.
I guess it comes down to the fact that if sys.filesystemencoding() is utf-8,
which in my case it is (on SunOS), I believe these conversion should be
Richard PALO added the comment:
curiously enough, I was able to test with python3.5.
The same errors result, and the same workaround seems to get over it.
--
___
Python tracker
<http://bugs.python.org/issue23
Richard PALO added the comment:
This turns out to be related to the locale environment set to 'C'.
A UTF-8 locale seems to get over the issue.
A fellow pkgsrc colleague filed an issue with lxml already relating to that
fact for the test suite (https://bugs.launchpad.net/lxml/+b
New submission from Richard Clifford:
The issue comes when there is a malformed HTTP request not ending in a new
line, it causes the server to hang, not timeout and causes a DoS.
The request that I sent to the server was as follows:
const char *headers = "GET / HTTP/1.1\r\nHost: localhost
New submission from Richard Futrell:
On Python 2.7.11, pickle.whichmodule(object.__new__, None) = 'email.MIMEAudio'
This is unlikely to be the correct module.
--
components: XML
messages: 261465
nosy: canjobear
priority: normal
severity: normal
status: open
title: pickle.w
Richard Futrell added the comment:
Ah, I get the same result as you in a clean interpreter session. Looks like
it's not Python's fault.
The bug seems to arise from an interaction with cloudpickle 0.2.1 (and only in
IPython), which puts the bad value into a cache somewhere in the pic
Richard PALO added the comment:
There *is* a feature with linking called $ORIGIN.
--
___
Python tracker
<http://bugs.python.org/issue19317>
___
___
Python-bug
Richard PALO added the comment:
oups... I meant to add the comment about $ORIGIN (not really useful here) but
also the fact that the binary python is built with the dependencies found via
the library path (-L, for example) and the eventual run-paths (-R or -runpath)
when not in the system
Richard PALO added the comment:
An example:
richard@omnis:/home/richard$ python2.7
Python 2.7.11 (default, Apr 27 2016, 04:35:25)
[GCC 4.9.3] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes
Richard PALO added the comment:
[fingers not yet warmed up] that is '/opt/local/lib/libmagic.so'
--
___
Python tracker
<http://bugs.python.org/issue19317>
___
__
New submission from Richard Neumann:
Currently Python's logging library has the Child-Separator hard-coded in
Logger.getChild() as '.'.
It would be useful to have the ability to preset this via an optional
basicConfig() argument like 'child_sep=' and preset it to &
Changes by Richard Neumann :
--
title: Add child seperator keyword to logging.basicConfig and use it in
Logger.getChild() -> Add child separator keyword to logging.basicConfig and use
it in Logger.getChild()
___
Python tracker
&l
Richard Neumann added the comment:
I am using loggers and sub-loggers (getChild()) in classes, which contain
sub-classes, wich contain sub-sub-classes and so on for complex data processing.
Hence I was using the logging library with sub-loggers to see in which of the
(sub-)classes things
Richard Neumann added the comment:
PS: @vinay.sajip
You do realize that I want this argument to be optional and to retain '.' as
default setting in order to keep the current behaviour?!
--
___
Python tracker
<http://bugs.python.o
Richard Neumann added the comment:
Added proposed patch
--
keywords: +patch
Added file: http://bugs.python.org/file42825/logger.patch
___
Python tracker
<http://bugs.python.org/issue26
Changes by Richard Neumann :
Removed file: http://bugs.python.org/file42825/logger.patch
___
Python tracker
<http://bugs.python.org/issue26999>
___
___
Python-bugs-list m
Changes by Richard Neumann :
Added file: http://bugs.python.org/file42827/logger.patch
___
Python tracker
<http://bugs.python.org/issue26999>
___
___
Python-bugs-list m
Richard Neumann added the comment:
I took the liberty to create a patch for Python v3.5.1.
--
keywords: +patch
nosy: +Richard Neumann
Added file: http://bugs.python.org/file42828/subprocess.patch
___
Python tracker
<http://bugs.python.org/issue25
Richard Neumann added the comment:
Please excuse my ambiguous phrasing.
What I meant was I created the patch _from_ the Python 3.5.1 module _for_
Python 3.6.
--
___
Python tracker
<http://bugs.python.org/issue25
Richard Neumann added the comment:
Thank you for the hint.
I never before contributed code to the python foundation and thus am not
familiar with the process.
I will look into it when I find the time.
--
___
Python tracker
<http://bugs.python.
New submission from Richard Penman:
I installed latest release
(https://www.python.org/downloads/release/python-351/) on OSX and get this
error:
$ python3
...
ImportError: This package should not be accessible on Python 3. Either you are
trying to run from the python-future src folder or
Richard Penman added the comment:
The full error log:
$ python3
Failed to import the site module
Traceback (most recent call last):
File "/usr/local/lib/python2.7/site-packages/site.py", line 75, in
__boot()
File "/usr/local/lib/python2.7/site-packages/site.py"
Richard Penman added the comment:
Apparently "The PYTHONPATH variable is used by all versions of Python 2 and
Python 3, so you should not permanently configure this variable unless it only
includes code that is compatible with all of your installed Python versions."
That s
New submission from Martin Richard:
base_subprocess.BaseSuprocessTransport implements
_make_write_subprocess_pipe_proto and _make_read_subprocess_pipe_proto.
Both are private and both raise NotImplementedError. However, when I grep in
tulip sources for those methods, they are never called nor
New submission from Martin Richard:
I would like to add a detach() method to base_suprocess.BaseSuprocessTransport,
which would release the underlying Popen object to the user, pretty much like
socket.detach() detaches a socket object and returns the fd.
The rationale is the following: the
New submission from Martin Richard:
Hi,
Currently, subprocess.Popen performs blocking IO in its constructor (at least
on Unix): it reads on a pipe in order to detect outcome of the pre-exec and
exec phase in the new child. There is no way yet to modify this behavior as
this blocking call is
New submission from K Richard Pixley :
Install the Python-2.7.2 mac installer for Lion on Lion.
Then attempt "easy_install -U psutil". I get:
za-dc-dev/bin/easy_install -U psutil
install_dir
/Users/rich/projects/za-packages/za-dependency-checker/za-dc-dev/lib/python2.7/sit
New submission from K Richard Pixley :
Once I've instantiated my server class, along with a handler class, called
server.serve_forever(), handler.handle() has been called, I've done my work,
and I'm ready to shut the whole thing down...
How do I do that?
The doc says server.
K Richard Pixley added the comment:
It appears as though the problem is that shutdown() blocks waiting for the
serve_forever loop to terminate, which won't happen as long as the process is
blocked on shutdown.
I'd like to propose that the library be changed to eliminate the block.
K Richard Pixley added the comment:
On second thought, my proposal is likely to break existing code, so I withdraw
it.
I don't know how to exit the server in a way that both works in all conditions
and also continues to support existing semantics.
I expect we'll need to create
K Richard Pixley added the comment:
My point was for python-2.7. I haven't stumbled into the buffer protocol yet.
So no, it doesn't really.
I still think the documentation, especially the 2.7 doc, could be more explicit.
My concern here is with the use of close() becoming obscure
K Richard Pixley added the comment:
An interesting point, although I think that's only relevant if the
documentation lists the ABC and a reference to it. (python-3 doc essentially
does this.)
I see no such reference in the 2.7 gzipfile doc, which leads me to believe,
(from the doc
K Richard Pixley added the comment:
I didn't miss it.
I think the close call needs equal treatment to the open call. The mention is
certainly present, but seems implicit to me. I would prefer to see it listed
explicitly.
But I also don't think it's important enough in
K Richard Pixley added the comment:
I'm now convinced this isn't worth fixing in 2.x.
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.py
New submission from K Richard Pixley :
mmap.read requires a argument. Since most file-like objects do not, this
breaks the file-like object illusion.
mmap.read argument should be optional, presumably defaulting to the entire
mmap'd area.
--
messages: 135362
nosy: rich-noir
pri
K Richard Pixley added the comment:
How does "rm -rf" address this issue? Or does it?
shutils.rmtree should probably do the same thing.
--
nosy: +teamnoir
___
Python tracker
<http://bugs.python.
K Richard Pixley added the comment:
Documentation needs to be updated to state that these are now context managers.
This is important since they aren't in python-2.x.
I'm not sure whether this should be added to the "new in python" blurbs.
--
New submission from K Richard Pixley :
The documentation for gzip should include the "close" method.
It's use in the 2.7 documentation implies it's existence but it should also be
stated explicitly that it exists.
In the 3.x documentation, the use of "close"
New submission from Richard B. Kreckel <[EMAIL PROTECTED]>:
When constructing a floating-point value, literals are apparently
sometimes interpreted as octal integral types, although they contain
exponent marker or/and decimal point. The presence of exponent marker
or/and decimal point
Richard B. Kreckel <[EMAIL PROTECTED]> added the comment:
Some additional information:
My original report was with an x86 system.
Now, I'm sitting in front of an x86_64 system running Python 2.4.4 (from
Debian stable) and Python 2.5.2 (from Debian testing), both 64 bit
userlan
K Richard Pixley added the comment:
I think a better solution that declaring it to be apple's bug would be to
release one binary for pre-10.7, (or maybe 10.6 with the current xcode), and a
different binary for post-10.7.
This isn't an apple "bug" in the sense that there&
Richard S. Gordon added the comment:
FYI: Here is an update to my subsequent bug report to the Cygwin project team.
You might find my answers to their questions useful in the future.
> Begin forwarded message:
>
> From: "Richard S. Gordon" mailto:rigo...@comcast.net>&
New submission from Richard S. Gordon:
Generated colors appear to be corrupted by overloading text attribute with
specified foreground and background colors.
This can be demonstrated by running test_tsWxColorPalette.py in Python 3x
(developer-sandbox) found in
https://github.com/rigordo959
Richard S. Gordon added the comment:
> On Jun 9, 2017, at 11:16 AM, STINNER Victor wrote:
>
>
> STINNER Victor added the comment:
>
>> Generated colors appear to be corrupted by overloading text attribute with
>> specified foreground and background colors.
Richard S. Gordon added the comment:
> On Jun 9, 2017, at 11:59 AM, Richard S. Gordon wrote:
>
>
>> On Jun 9, 2017, at 11:16 AM, STINNER Victor wrote:
>>
>>
>> STINNER Victor added the comment:
>>
>>> Generated colors appear to
Richard S. Gordon added the comment:
> On Jun 9, 2017, at 12:32 PM, STINNER Victor <mailto:rep...@bugs.python.org>> wrote:
>
>
> STINNER Victor added the comment:
>
> What is your operating system? How did you install ncurses? What is your
> ncurses version?
&
Richard S. Gordon added the comment:
> On Jun 9, 2017, at 4:41 PM, STINNER Victor wrote:
>
>
> STINNER Victor added the comment:
>
> Cygwin is not currently supported by CPython, so I suggest to close this
> issue. I mean: please report the issue t
Richard S. Gordon added the comment:
> On Jun 9, 2017, at 4:59 PM, Richard S. Gordon wrote:
>
>
> Richard S. Gordon added the comment:
>
>> On Jun 9, 2017, at 4:41 PM, STINNER Victor wrote:
>>
>>
>> STINNER Victor added the comment:
>>
>&g
Richard S. Gordon added the comment:
> On Jun 10, 2017, at 4:28 AM, Richard S. Gordon wrote:
>
>
>> On Jun 9, 2017, at 4:59 PM, Richard S. Gordon > <mailto:rep...@bugs.python.org>> wrote:
>>
>>
>> Richard S. Gordon added the comment:
>&
Richard S. Gordon added the comment:
Clarification:
The suggested fix to the Python 3.6.1 curses stdlib should only be applied to
those 64-bit platform version used with 64-bit ncurses 6.0.
It should NOT apply to the Python 3.6.1 curses stdlib applied to those 32-bit
platforms used with 32-bit
Richard S. Gordon added the comment:
> On Jun 9, 2017, at 5:41 PM, Terry J. Reedy wrote:
>
>
> Terry J. Reedy added the comment:
>
> Richard, when replying by email, please strip quoted text except for an
> occasional line or two. (See example of limited in-context quo
Richard S. Gordon added the comment:
> On Jun 9, 2017, at 4:57 PM, Masayuki Yamamoto wrote:
>
>
> Masayuki Yamamoto added the comment:
>
> @rigordo Are you using mintty? If I remember rightly, mintty hasn't been set
> 256 colors after installation (at least in
New submission from K Richard Pixley:
There's a problem with tarfile. Write a program to traverse the contents of a
modest sized tar archive. Make sure your tar archive is compressed. Then read
the tar archive with your program.
I'm finding that allowing tarfile to read a
K Richard Pixley added the comment:
New info...
I see the degradation on most of the linux boxes I've tried:
* ubuntu-13.04, (raring), 64-bit
* rhel-5.4 64-bit
* rhel-5.7 64-bit
* suse-11 64-bit
I see some degradation on MacOsX-10.8.4 but it's in the acceptable range, more
like 2
K Richard Pixley added the comment:
Here's a script that tests for the problem.
--
Added file: http://bugs.python.org/file31303/tarproblem.py
___
Python tracker
<http://bugs.python.org/is
K Richard Pixley added the comment:
I see your point.
The alternative would be to limit the size of archive that can be extracted
from to the size of virtual memory, which is essentially what I'm doing
manually. Either way, someone will be surprised. I'm not which which way will
New submission from Richard s. Gordon:
Curses bug report for Python 2.7 and Python 3.2
My Python code outputs text properly with xterm and xterm-16color. It does not
work properly with xterm-88color and xterm-256color (after defining RGB color
pallet) when run on Python-2.7 and Python-3.2 on
Richard B. Kreckel added the comment:
I just tried Python 2.6 (r26:66714, Feb 21 2009, 05:33:00) from SUSE
Linux Enterprise Server 11 (i586) and it didn't fail. This appears to
have been fixed, somehow.
--
___
Python tracker
<http://bugs.py
Changes by Richard s. Gordon :
--
nosy: eclectic9509
priority: normal
severity: normal
status: open
title: Python 3.6.0b4 Reports ncurses present in Cygwin but fails to build for
cygwin
___
Python tracker
<http://bugs.python.org/issue28
Changes by Richard S. Gordon :
--
components: Build
nosy: rigordo
priority: normal
severity: normal
status: open
title: Python 3.6.0b4 Reports ncurses present in Cygwin but fails to build for
Cygwin
versions: Python 3.6
___
Python tracker
<h
Changes by J Richard Snape :
--
nosy: +J Richard Snape
___
Python tracker
<http://bugs.python.org/issue25294>
___
___
Python-bugs-list mailing list
Unsubscribe:
Richard van den Berg added the comment:
I just ran into this 12 year old issue. Can this be merged please?
--
nosy: +richard.security.consultant
___
Python tracker
<https://bugs.python.org/issue5
Richard van den Berg added the comment:
Here is the updated patch. Is python5004-test.c enough as a test case?
--
Added file: https://bugs.python.org/file50390/python2.7-socket-getfqdn.patch
___
Python tracker
<https://bugs.python.org/issue5
Richard van den Berg added the comment:
In that case Stijn Hope should create the PR since he wrote the patch. Anyone
else could get in trouble for using his code without proper permission.
--
___
Python tracker
<https://bugs.python.org/issue5
1001 - 1064 of 1064 matches
Mail list logo
