Greg Roodt added the comment:
I've made the minor edits required after the review to my simplification of the
first example.
David, perhaps we combine our efforts? Use my simple first example to explain
the very basics, then continue the explanation with the pizza example?
Im happy e
Greg Roodt added the comment:
I can add some more info to the docs if anybody feels they are required, but I
think they are sufficient. It already mentions that it copies file contents and
that the correct permissions are required.
This is mentioned in the docs for shutil.copyfile:
The
Greg Roodt added the comment:
By the way, the issue can be recreated by running the following:
netcat -l -p -e "echo HTTP/1.1 1000 OK" &
python -c "import urllib2; urllib2.urlopen('http://localhost:')"
This happens on
Greg Ward added the comment:
Random comments from original author of textwrap.py, in case anyone cares at
this point...
* This is a pretty obscure edge case, and I admit that it never occurred to me
when writing the code. (If it had, I would have tested it!)
* One can debate endlessly about
Changes by Greg Stein :
--
nosy: -gstein
___
Python tracker
<http://bugs.python.org/issue15653>
___
___
Python-bugs-list mailing list
Unsubscribe:
Greg Couch added the comment:
On Thu, 18 Oct 2012, Trent Nelson wrote:
> Trent Nelson added the comment:
>
> Hi Greg,
>
>I realize it's been a good five years since you first raised this
>issue, but I was wondering if you ever ended up making any progress
>
New submission from Greg Ward:
When using shutil.copytree() on Linux to copy to a VFAT filesystem, it crashes
like this:
Traceback (most recent call last):
File "/data/src/cpython/3.4/Lib/shutil.py", line 336, in copytree
copystat(src, dst)
File "/data/src/cpython/3.
Greg Ward added the comment:
In 3.3 and earlier, copytree() crashes roughly as described in issue1545, with
shutil.Error that wraps the underlying "Operation not permitted" error from
trying to chmod() something in a VFAT filesystem. Since this appears to
accurately reflect what
Greg Ward added the comment:
Bad news: because reproducing this requires sudo (to mount an arbitrary
filesystem), I'm not sure it's possible/desirable to add test code for it.
Good news: the fix is trivial, and it passes my manual test. Here's a patch:
--- a/Lib/shutil.py
+++
Greg Hellings added the comment:
I'm trying to cross-compile the latest default out of Mercurial based on the
status of this. Currently it fails with the following invocation:
$ ../configure --host=i686-w64-mingw32 --build=x86_64-redhat-linux-gnu
--target=i686-w64-mingw32 --prefix=/usr
Greg Hellings added the comment:
Bummer, the patches in that issue do not apply cleanly to either the 3.3.0
released tarball nor to the 3.3 branch from hg.
--
___
Python tracker
<http://bugs.python.org/issue3
Greg Couch added the comment:
In my opinion, the Python 2.7 results are wrong.
In Python 2.7, inspect.ismethod returns True for both bound and unbound methods
-- ie., is broken according to the documentation. As a workaround, I'm using:
def is_bound_method(obj):
return hasatt
Greg Ward added the comment:
>>> import this
[...]
There should be one-- and preferably only one --obvious way to do it.
--
nosy: +gward
___
Python tracker
<http://bugs.python.or
New submission from Greg Harris:
When interacting with librt via a ctypes.Structure object I can reliably cause
the python interpreter to crash during Py_Finalize *after* all of my code has
executed. It appears to only happen on structures that have been passed to the
mq_getattributes call
New submission from Greg Baker :
I believe what I'm seeing here is somewhat related to issue 670664, but
is easier to handle because of the CDATA structure. Basically,
HTMLParser doesn't recognize CDATA sections at all, so their content is
incorrectly parsed like normal data.
The fo
New submission from Greg Hewgill :
Based on a short discussion on python-dev:
http://mail.python.org/pipermail/python-dev/2009-November/094306.html
the "Warning" box in the documentation for sys.exc_info needs to be
updated in light of PEP 3134, and perhaps moved elsewhere since the
Greg Ward added the comment:
> but I feel there is a better and more general
> solution - just provide some minimal formatting for description: treat
> empty line as paragraph separator. Then I would be able to add example
> or anything else to the description formatting it as neces
New submission from Greg Hewgill :
Quite by accident, I came across a case where Python would quit
generating traceback text and skip printing the actual exception
information. Here is a sample program:
exec(compile("spam()", ".", "exec"))
and the output in P
Greg Ward added the comment:
> Greg, any comment on this issue?
Yes, two:
1) textwrap does not handle paragraphs or paragraph breaks in any way.
That was a deliberate limitation to keep the code from getting any
hairier. People have complained about this in the past, and I h
Greg Couch added the comment:
FYI, I was able to work around this and use an unmodified Python by
subtyping type and overriding the setattr method as shown below. It's a
lot messier than patching Python.
static int
Mutable_SetAttr(PyObject *obj, PyObject *name, PyObject *
Changes by Greg Bakker :
--
nosy: +gregb
___
Python tracker
<http://bugs.python.org/issue5403>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Greg Hazel added the comment:
IE renamed the file for me. So this is not uncommon.
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue1
New submission from Greg Holling :
We have an application that calls a 3rd party library that returns a
structure (by value) from a callback. I'm including some sample code
that duplicates the behavior. The problem is that return types from
callbacks cannot be anything other than s
Greg Couch added the comment:
I like the C patch better. It only tries to decode non-unicode objects
with the filesystem (mbcs) encoding. This fits in with Python 3.0
perfectly where all strings are unicode. In 2.5, strings are assumed to
be in the mbcs encoding, to match the Windows ANSI
Greg Ward added the comment:
I just took a look at the original patch uploaded by drtimcouper. IMHO
it would be cleaner and simpler to modify optparse.py so that it behaves
as consistently as possible under Jython and CPython. For example,
optparse should catch the ValueError raised when a
Changes by Greg Ward :
--
components: +Library (Lib) -Tests
title: test_optparse.py mod. for jython -> optparse tests fail under Jython
___
Python tracker
<http://bugs.python.org/issue1
New submission from Greg Couch :
Sometime around Python 2.5.4, Menu.delete was changed to delete
associated entry commands (and thus plug a memory leak). This broke
Pmw.OptionMenu because it already had similar code, so when Menu.delete
was called, the commands were already gone, and a TclError
Changes by Greg Couch :
Added file: http://bugs.python.org/file14266/delcmd.patch
___
Python tracker
<http://bugs.python.org/issue6270>
___
___
Python-bugs-list mailin
Changes by Greg Couch :
Removed file: http://bugs.python.org/file14265/delcmd.patch
___
Python tracker
<http://bugs.python.org/issue6270>
___
___
Python-bugs-list mailin
Greg Ward added the comment:
> This is an edited-down excerpt form the optparse documentation from:
>
> http://docs.python.org/library/optparse.html
>
> "... the traditional Unix syntax is a hyphen (“-“) followed by a
> single letter [...] Some other option syntaxes
Changes by Greg Ward :
--
title: optparse -> optparse: clarify option concatenation in docs
___
Python tracker
<http://bugs.python.org/issue>
___
___
Py
Greg Słodkowicz added the comment:
Doesn't breaking installation of packages on a major platform warrant a quicker
release of a fix?
--
nosy: +Greg.Slodkowicz
___
Python tracker
<http://bugs.python.org/i
Greg Hazel added the comment:
Searching the file for "raise" is sort of pointless, since exec() takes a
string which might have come from anywhere, and there might be any number of
exec() calls in the module. See: http://codepad.org/7EBMhb0O
There are at least two reasonable an
New submission from Greg Hazel :
Probably applies to more versions, but I only tested on 2.5.2 and 2.6.5.
Distutils incorrectly constructs paths for the build/temp directory when
relative paths are used in the "sources" list. This can result in failing to
make the build/temp direct
Greg Hazel added the comment:
This is still an issue.
The bug I'm reporting had been explained well, I thought, but I'll repeat it in
summary:
There is no way to pass around traceback objects without holding references to
an excessive number of objects.
Traceback raising typicall
Greg Hazel added the comment:
The objects I do want in the traceback are the objects necessary to print a
traceback, but not the locals and globals of each frame.
For example:
def bar():
x = "stuff"
raise Exception("example!")
bar()
prints:
Traceback (most recent
Greg Hazel added the comment:
It seems this is partially addressed in a big red "Warning" section of the docs
on sys.exc_info:
http://docs.python.org/release/3.1/library/sys.html#sys.exc_info
and is captured in the "Open Issue: Garbage Collection" section for PEP-3134:
h
Greg Hazel added the comment:
It depends on how you look at it. Those two issues describe the surprising
behavior of the same references I'm talking about here, when the lifetime of
the traceback reference is only inside the same frame. This ticket describes
the surprising behavior of
Greg Hazel added the comment:
> you should *expect* all those values to persist, so that shouldn't be
> "surprising".
It's not something I expected, and the warnings around traceback objects are a
good indication that other developers have not expected it either. O
Greg Ward added the comment:
> Is it too late for 2.7?
I have no idea.
It does look as though someone has written unit tests for distutils, so the
patch needs a test change too. Henrique?
--
stage: -> unit test needed
___
Python tracker
Greg Brockman added the comment:
For what it's worth, I think I have a simpler reproducer of this issue. Using
freshly-compiled python-from-trunk (as well as multiprocessing-from-trunk), I
get tracebacks from the following about 30% of the time:
"""
import m
Greg Brockman added the comment:
I'm on Ubuntu 10.04, 64 bit.
--
___
Python tracker
<http://bugs.python.org/issue4106>
___
___
Python-bugs-list mailing list
New submission from Greg Brockman :
I have recently begun using multiprocessing for a variety of batch
jobs. It's a great library, and it's been quite useful. However, I have been
bitten several times by situations where a worker process in a Pool will
unexpectedly di
New submission from Greg Brockman :
On Ubuntu 10.04, using freshly-compiled python-from-trunk (as well as
multiprocessing-from-trunk), I get tracebacks from the following about 30% of
the time:
"""
import multiprocessing, time
def foo(x):
Greg Brockman added the comment:
Sure thing. See http://bugs.python.org/issue9207.
--
___
Python tracker
<http://bugs.python.org/issue4106>
___
___
Python-bug
Greg Brockman added the comment:
That's likely a mistake on my part. I'm not observing this using the stock
version of multiprocessing on my Ubuntu machine(after running O(100) times). I
do, however, observe it when using either python2.7 or python2.6 with
multiprocessing-from
Greg Brockman added the comment:
No, I'm not using the Google code backport.
To be clear, I've tried testing this with two versions of multiprocessing:
- multiprocessing-from-trunk (r82645): I get these exceptions with ~40%
frequency
- multiprocessing from Ubuntu 10.04 (version 0
Greg Brockman added the comment:
> Wait - so, you are pulling svn trunk, compiling and running your test
> with the built python executable?
Yes. I initially observed this issue while using 10.04's Python (2.6.5), but
wanted to make sure it wasn't fixed by using a newer int
Greg Brockman added the comment:
Yeah, I've just taken a checkout from trunk, ran './configure && make && make
install', and reproduced on:
- Ubuntu 10.04 32-bit
- Ubuntu 9.04 32-bit
--
___
Python tracker
&l
Greg Brockman added the comment:
With the line commented out, I no longer see any exceptions.
Although, if I understand what's going on, there still a (much rarer)
possibility of an exception, right? I guess in the common case, the
worker_handler is in the sleep when shutdown begins.
Greg Brockman added the comment:
Think http://www.mail-archive.com/python-l...@python.org/msg282114.html is
relevant?
--
___
Python tracker
<http://bugs.python.org/issue9
Greg Brockman added the comment:
Cool, thanks. I'll note that with this patch applied, using the test program
from 9207 I consistently get the following exception:
"""
Exception in thread Thread-1 (most likely raised during interpreter shutdown):
Traceback (most recen
Greg Brockman added the comment:
What about just catching the exception? See e.g. the attached patch.
(Disclaimer: not heavily tested).
--
Added file: http://bugs.python.org/file17934/shutdown.patch
___
Python tracker
<http://bugs.python.
Greg Brockman added the comment:
With pool.py:272 commented out, running about 50k iterations, I saw 4
tracebacks giving an exception on pool.py:152. So this seems to imply the race
does exist (i.e. that the thread is in _maintain_pool rather than time.sleep
when shutdown begins). It looks
Greg Brockman added the comment:
Thanks much for taking a look at this!
> why are you terminating the second pass after finding a failed
> process?
Unfortunately, if you've lost a worker, you are no longer guaranteed that cache
will eventually be empty. In particular, you may
Greg Brockman added the comment:
> For processes disappearing (if that can at all happen), we could solve
> that by storing the jobs a process has accepted (started working on),
> so if a worker process is lost, we can mark them as failed too.
Sure, this would be reasonable behavio
Greg Brockman added the comment:
> What kind of errors are you having that makes the get() call fail?
Try running the script I posted. It will fail with an AttributeError (raised
during unpickling) and hang.
I'll note that the particular issues that I've run into in practice ar
Greg Brockman added the comment:
This looks pretty reasonable to my untrained eye. I successfully applied and
ran the test suite.
To be clear, the errback change and the unpickleable result change are actually
orthogonal, right? Anyway, I'm not really familiar with the protocol here
Greg Brockman added the comment:
While looking at your patch in issue 9244, I realized that my code fails to
handle an unpickleable task, as in:
"""
#!/usr/bin/env python
import multiprocessing
foo = lambda x: x
p = multiprocessing.Pool(1)
p.apply(foo, [1])
""&quo
Greg Brockman added the comment:
Before I forget, looks like we also need to deal with the result from a worker
being un-unpickleable:
"""
#!/usr/bin/env python
import multiprocessing
def foo(x):
global bar
def bar(x):
pass
return bar
p = multiprocessing.Pool(1)
New submission from Greg Hazel :
ctypes on Windows on a 64bit Python installation gets a NULL pointer access
where one is not expected.
To reproduce the problem, run make.bat then "python ctypes_test.py"
Failure output looks like this:
Three! 1 2 <__main__.LP_S
Greg Brockman added the comment:
>> Before I forget, looks like we also need to deal with the
>> result from a worker being un-unpickleable:
>This is what my patch in bug 9244 does...
Really? I could be misremembering, but I believe you deal with the case of the
result bei
Greg Brockman added the comment:
Actually, the program you demonstrate is nonequivalent to the one I posted.
The one I posted pickles just fine because 'bar' is a global name, but doesn't
unpickle because it doesn't exist in the parent's namespace. (See
http:
Greg Brockman added the comment:
Started looking at your patch. It seems to behave reasonably, although it
still doesn't catch all of the failure cases. In particular, as you note,
crashed jobs won't be noticed until the pool shuts down... but if you make a
blocking call such
Changes by Greg Hazel :
Removed file: http://bugs.python.org/file18012/ctypes_test.zip
___
Python tracker
<http://bugs.python.org/issue9266>
___
___
Python-bugs-list m
Greg Hazel added the comment:
Ok, this issue is worse, and much easier to reproduce, than I thought. Here is
an updated ctypes_test.zip with a repro using only integers and callbacks.
Correct output:
('three', (1, 2, 3))
('four', (1, 2, 3, 4))
('five', (1,
Changes by Greg Hazel :
--
nosy: +ghazel
___
Python tracker
<http://bugs.python.org/issue6792>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Changes by Greg Hazel :
--
nosy: +ghazel
___
Python tracker
<http://bugs.python.org/issue7171>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Greg Brockman added the comment:
At first glance, looks like there are a number of sites where you don't change
the blocking calls to non-blocking calls (e.g. get()). Almost all of the
get()s have the potential to be called when there is no possibility for them to
terminate.
I
Greg Hazel added the comment:
In addition, inet_ntop and inet_pton can be implemented on Windows platforms
prior to Vista using WSAAddressToStringA and WSAStringToAddressA.
--
___
Python tracker
<http://bugs.python.org/issue7
Greg Brockman added the comment:
> I thought the EOF errors would take care of that, at least this has
> been running in production on many platforms without that happening.
There are a lot of corner cases here, some more pedantic than others. For
example, suppose a child dies while h
Changes by Greg Brockman :
--
nosy: +gdb
___
Python tracker
<http://bugs.python.org/issue9334>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Greg Brockman added the comment:
> You can't have a sensible default timeout, because the worker may be
> processing something important...
In my case, the jobs are either functional or idempotent anyway, so aborting
halfway through isn't a problem. In general though, I'
Greg Brockman added the comment:
Thanks for the comment. It's good to know what constraints we have to deal
with.
> we can not, however, change the API.
Does this include adding optional arguments?
--
___
Python tracker
<http://bugs
Greg Malcolm added the comment:
I've uploaded a patch for 3.2 that throws a ValueError exception for non
numeric port numbers and SMTPSocketConnectError for socket connection failures.
This patch introduces an API change, by creating the SMTPSocketConnectError
which provides inform
Greg Couch added the comment:
So Terry, can you reopen this bug then? It's not out of date.
--
___
Python tracker
<http://bugs.python.org/issue1759845>
___
___
New submission from Greg Brockman :
Upon os.fork(), pending signals are inherited by the child process. This can
be demonstrated by pressing C-c in the middle of the
following program:
"""
import os, sys, time, threading
def do_fork():
while True:
New submission from Greg Solomon:
https://docs.python.org/3/library/itertools.html#itertools.groupby
I found the "equivalent" code a bit hard to read. Is there any merit in
changing it to something a bit like the following ?
Kind Rgds, Greg
class groupby:
def __init__( self
Greg Solomon added the comment:
Oh, I get it. There needs to be a next(self.it) loop in __next__ as well as in
_grouper in case the user doesn't call _grouper.
My test was
for ( k , g ) in groupby( L ):
print ( k , len( list( g ) ) )
so I was executing _grouper on every row.
T
Greg Bengeult added the comment:
Here's a revised patch file for Python 3.7. This is my first ever submission to
an open source project, so please be gentle.
--
nosy: +gbengeult
versions: -Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file46132/csv.rst-
Greg Bengeult added the comment:
I have attached a patch for 2.7 that adds -b and -bb to the command line
documentation in Modules/main.c and Doc/library/cmdline.rst, following the
suggested text provided by Martin.
Interestingly, unicode(), bytearray(), and str() don't seem to be trans
Greg Ward added the comment:
LGTM, after a cursory glance at the code history. Been a lng time since I
understood this stuff deeply, though!
--
___
Python tracker
<http://bugs.python.org/issue29
Greg Bengeult added the comment:
Thanks for the :class: markup edits. I'm still learning this stuff.
--
___
Python tracker
<http://bugs.python.org/is
Greg Bengeult added the comment:
How about this documentation patch for tzset()? Most of the verbiage comes from
the Linux tzset() man page. I can also generate a similar patch for 2.7 if it's
needed.
--
nosy: +gbengeult
versions: +Python 3.7
Added file: http://bugs.pytho
Greg Bengeult added the comment:
Here's the 2.7 patch.
--
Added file: http://bugs.python.org/file46276/tzset_rst_27.patch
___
Python tracker
<http://bugs.python.org/is
New submission from Greg Stark:
In my experiments with the relatively new class SSLObject from the ssl module
I've noticed the following behavior(s) which I think can be described as bugs.
The getpeercert() method raises a ValueError exception "handshake not done"
even after th
Greg Stark added the comment:
Christian,
I will gladly do so a little later today. Thanks for your quick response.
--greg
On Fri, Jan 20, 2017 at 7:29 AM, Christian Heimes
wrote:
>
> Christian Heimes added the comment:
>
> Hi Grek,
>
> can you provide a script to rep
Greg Stark added the comment:
adding script the illustrates the bug.
--
Added file: http://bugs.python.org/file46364/sslbugs.py
___
Python tracker
<http://bugs.python.org/issue29
Greg Onufer added the comment:
32-bit and 64-bit SPARC ABIs have 64-bit integer data types.
SPARC, like many RISC architectures, also has natural alignment requirements.
Attempting to dereference a pointer to a 4-byte-sized object requires 4-byte
alignment, for example. 2-byte-sized objects
New submission from Greg Stark:
This is not a bug, but rather a request for API improvements.
Correct SSL shutdown processing is frequent source of confusion. Python’s ssl
module unfortunately lacks the flexibility to accommodate some common
paradigms.
The problem is that the unwrap
New submission from Greg Stark:
The file Test/test_float.py has a decorator for tests that must be skipped on
non-IEEE machines. However just eyeballing it it seems there are a few tests
that test behaviour around Inf and NaN that are lacking this decorator.
Alternately it's possible th
Greg Stark added the comment:
I can easily grant you access to mine. It's a bit slow but you can quickly poke
around with the state in the backtrace which honestly looks to me like it
should be enough to spot the problem.
There are other options. There's a good emulato
Greg Stark added the comment:
I certainly understand the limitations of volunteer projects. I know you have
limited resources and can't test on every platform. That's actually exactly why
I'm testing on this platform and why I reported the bug. If there's any
addition
Greg Stark added the comment:
Well I was able to minimize the actual cause:
$ /usr/pkg/bin/python -c 1e300*1e300
[1] Floating point exception /usr/pkg/bin/python -c 1e300*1e300
I noticed that the constant folding arithmetic is protected by
"PyFPE_START_PROTECT" macros so I wonder
Greg Ward added the comment:
The particular use case that triggered this: Mercurial's test suite. It runs
"hg blah blah" and compares the output against known good output. But
Mercurial's output is just bytes, because pretty much everything in a Mercurial
repo is just
Greg Ward added the comment:
The original reproduction I posted was incorrect -- it makes difflib look worse
than it should. (I passed strings rather than lists of strings.) Here is a more
accurate version:
>>> import difflib
>>> a = [b'hello']
>>> b = [b
Greg Ward added the comment:
Replying to Terry Reedy:
> So a dual string/bytes function would not be completely trivial.
Correct. I have one working, but it makes my eyes bleed. I fail ashamed to have
written it.
> Greg, can you convert bytes to strings, or strings to bytes
Nope. Here
Greg Ward added the comment:
OK I now have two competing patches. Both are disgusting, but in different ways.
1) http://hg.gerg.ca/cpython/rev/fcf3d27f20d9
- factor out all the string constants
- always concatenate, do not .format()
2) http://hg.gerg.ca/cpython/rev/cebefce2cfd4
- copy
Greg Ward added the comment:
Take 3: http://hg.gerg.ca/cpython/rev/78bdb10551ee
- uses surrogateescape as suggested by Antoine
- seems to work
--
___
Python tracker
<http://bugs.python.org/issue17
Greg Ward added the comment:
Thanks for the review, Terry! Here is a revised patch, now on trunk:
http://hg.gerg.ca/cpython/rev/6dedcdbe7cd5
I believe I have addressed all of your concerns.
Note also that the tests now highlight some dubious behaviour. Further feedback
is welcome!
I&#
201 - 300 of 337 matches
Mail list logo
