Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12075
___
New submission from Nick Coghlan:
logging.shutdown includes a try/except block to avoid emitting spurious IO
errors while the interpreter is shutting down. This fails if a registered
handler tries to do IO (such as calling flush()) in its release method.
It would be better if the
Changes by Nick Coghlan ncogh...@gmail.com:
--
nosy: +vinay.sajip
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15960
___
___
Amaury Forgeot d'Arc added the comment:
And why isn't \ggroupname part of the pattern language, anyway, or at
least some way to refer to a match made in a previous *named* group?
But this way exists: (?P=startquote) is what you want. To me \g is an
exception, and frankly I did not know
Michele Orrù added the comment:
Something like this? That's a pretty trivial draft for the patch.
About byte sequences, those features should be available using builtins
bin(), oct() and hex(), hacking on __index__, or with internal methods?
I am lacking imagination, what else there should be
Stefan Krah added the comment:
So the problem is that readinto(view) might result in several references
to view? I don't think that can be solved on the memoryview side.
One could do:
view = PyMemoryView_FromObject(b);
// Lie about writability
((PyMemoryViewObject
Richard Oudkerk added the comment:
Then the view owns a reference to the bytes object. But that does not
solve the problem that writable memoryviews based on a readonly object
might be hanging around.
How about doing
PyObject_GetBuffer(b, buf, PyBUF_WRITABLE);
view =
New submission from Malthe Borch:
When ``docutils`` are importable, distutils uses a reporter implementation that
incorrectly drops a return value from the ``system_message`` override (see
patch).
--
assignee: eric.araujo
components: Distutils
files: patch.diff
keywords: patch
New submission from Nacsa Kristóf:
The Python docs faq says that due to a bug in Windows NT's cmd.exe, the output
redirection and piping won't work when started from file extension.
http://docs.python.org/faq/windows.html#how-do-i-make-python-scripts-executable
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
keywords: +easy
nosy: +brian.curtin, terry.reedy, tim.golden
stage: - needs patch
type: - enhancement
versions: -Python 2.6, Python 3.1
___
Python tracker rep...@bugs.python.org
Changes by Michele Orrù maker...@gmail.com:
--
nosy: +maker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8425
___
___
Python-bugs-list mailing
Richard Oudkerk added the comment:
The current non-test uses of PyMemoryView_FromBuffer() are in
_io.BufferedReader.read(), _io.BufferedWriter.write(), PyUnicode_Decode().
It looks like they can each be made to leak a memoryview that references a
deallocated buffer. (Maybe the answer is
Changes by Trent Nelson tr...@snakebite.org:
--
title: Numerous utime ns tests fail on FreeBSD w/ ZFS - Numerous utime ns
tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS)
___
Python tracker rep...@bugs.python.org
Changes by Kristof Keppens kkepp...@gmail.com:
--
nosy: +Kristof.Keppens
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9720
___
___
New submission from Trent Nelson:
Gripe: if you want a 64-bit, non-gcc (i.e. vendor's cc) build on a proprietary
UNIX system (i.e. Solaris, HP-UX, AIX etc), you're going to have a bad time.
Coercing a 64-bit build from a vendor's cc currently requires explicit
CFLAGS/LDFLAGS/configure
Trent Nelson added the comment:
On the s10 slave (Solaris 10/nitrogen) for 3.x:
(cpython@nitrogen:ttypts/4) (Tue/12:32) ..
% ../../src/configure --with-pydebug
Christian Heimes added the comment:
Serhiy:
If I understand you correctly it should be easy to fix. The code in close() has
to check if any file is beyond the ZIP64 limit and then write all headers with
extra args. Is that correct?
--
keywords: +needs review
nosy: +christian.heimes
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15963
___
___
New submission from Chris Jerdonek:
Building with--
./configure --with-pydebug make -j2
errors out after switching branches from default to 2.7 when the system Python
is Python 3 (on Mac OS X 10.7.4 using MacPorts).
To reproduce:
$ sudo port select python python32
$ python
No such file or
Vinay Sajip added the comment:
I'm not against making this change, but I'm curious - why would a handler do
clean-up I/O in its release() method (which is just for releasing the I/O lock)
where it could just as easily override the close() method to do the same thing?
It seems like programmer
New submission from Trent Nelson:
On Solaris (s10/nitrogen):
% find /usr/include -type f | xargs fgrep -ni AT_FDCWD
/usr/include/sys/fcntl.h:320:#defineAT_FDCWD
0xffd19553
(AIX uses -2, FreeBSD uses -100.)
Anyway, that results in:
(cpython@nitrogen:ttypts/10)
Changes by R. David Murray rdmur...@bitdance.com:
--
nosy: +larry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15965
___
___
Python-bugs-list
Trent Nelson added the comment:
Easy fix, cast AT_FDCWD to (int):
% hg diff
diff -r 3a880d640981 Modules/posixmodule.c
--- a/Modules/posixmodule.c Tue Sep 18 07:21:18 2012 +0300
+++ b/Modules/posixmodule.c Tue Sep 18 16:04:58 2012 +
@@ -414,7 +414,14 @@
#ifdef AT_FDCWD
New submission from Mark Dickinson:
The submit methods of concurrent.futures.ThreadPoolExecutor and
concurrent.futures.ProcessPoolExectutor raise TypeError when submitting a
callable with a keyword argument named 'fn' or 'self':
Python 3.3.0rc2+ (default:3a880d640981, Sep 18 2012,
Trent Nelson added the comment:
Closing issue; this has been fixed.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2286
___
Mark Dickinson added the comment:
Here's a patch. The solution is ugly enough that I'm wondering whether this is
even worth fixing.
--
keywords: +patch
Added file: http://bugs.python.org/file27216/futures.patch
___
Python tracker
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15955
___
___
Python-bugs-list
Éric Araujo added the comment:
Thanks for the report. I think the wiki was modified to redirect /thing to
/moin/thing some months ago, so it may be the recent hardware migration that
broke that. I’ll follow up with the pydotorg-www mailing list (or feel free to
do it).
--
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +eric.araujo, loewis
versions: -Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15963
___
Éric Araujo added the comment:
Thanks for the report and patch. I think a similar issue was reported for
distutils2 (maybe only orally, not on this tracker, I have to search). How did
you find the bug? In other words, can you add a unit test for this? :)
--
components: +Distutils2
Michael Foord added the comment:
The patch is just waiting for me to look over it and commit. I'll get to it
ASAP.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15836
___
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4711
___
___
Python-bugs-list
Vitaly added the comment:
In the work-around, we need to watch out for what 'man 2 read' on Mac OS refers
to as normal file:
==
Upon successful completion, read(), readv(), and pread() return the number of
bytes actually read and placed in the buffer. *The system guarantees to
read the
Changes by Ralf Schmitt python-b...@systemexit.de:
--
nosy: +schmir
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15896
___
___
Python-bugs-list
Matthew Barnett added the comment:
There needed to be a way of referring to named groups in the replacement
template. The existing form \groupnumber clearly wouldn't work. Other regex
implementations, such as Perl, do have \g and also \k (for named groups).
In my implementation I added
Richard Oudkerk added the comment:
I am rather confused about the ownership semantics when one uses
PyMemoryView_FromBuffer().
It looks as though PyMemoryView_FromBuffer() steals ownership of the buffer
since, when the associated _PyManagedBufferObject is garbage collected,
Stefan Krah added the comment:
Richard Oudkerk rep...@bugs.python.org wrote:
PyObject_GetBuffer(b, buf, PyBUF_WRITABLE);
view = PyMemoryView_FromBuffer(buf);
// readinto view
PyBuffer_Release(buf);
Would attempts to access a leaked reference to view now result in
Stefan Krah added the comment:
Richard Oudkerk rep...@bugs.python.org wrote:
The documentation is not very helpful. It just says that calls
to PyObject_GetBuffer() must be matched with calls to PyBuffer_Release().
Yes, we need to sort that out, see #15821.
--
Trent Nelson added the comment:
Solaris 10 release (i.e. optimized) build requires the following:
../../src/configure --without-gcc CFLAGS=-v -fsimple=0 -m64 -mt=yes -xbuiltin
-xhwcprof -xF -xarch=native -xchip=native -fma=fused -g -xO5 -xlibmil -xlibmopt
-xmemalign=8s -xregs=frameptr
Steve Newcomb added the comment:
But this way exists: (?P=startquote) is what you want.
I know how I missed it: I searched for backref in the documentation. I did
not find it in the discussion of the pattern language, because that word does
not appear where ?P= is discussed.
contributions
New submission from Trent Nelson:
All my slaves' /tmp's are polluted with regrtest fluff. I haven't checked yet,
but I presume no cleanup is done if a test/run fails.
nitrogen% find /tmp -user cpython 2 /dev/null | wc -l
197
netbsd51-x64-1$ find /tmp -user cpython 2 /dev/null | wc -l
142
Charles-François Natali added the comment:
What's wrong with working around this bug by reading a smaller amount?
How much data is there supposed to be?
Nothing, except that there are probably other places in the stdlib
where we can get bitten by this bug. Note that this should eventually
be
Changes by Eric V. Smith e...@trueblade.com:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15039
___
Larry Hastings added the comment:
Lgtm.
Trent Nelson rep...@bugs.python.org wrote:
Trent Nelson added the comment:
Easy fix, cast AT_FDCWD to (int):
% hg diff
diff -r 3a880d640981 Modules/posixmodule.c
--- a/Modules/posixmodule.c Tue Sep 18 07:21:18 2012 +0300
+++
Amaury Forgeot d'Arc added the comment:
Thanks for the patch! The new formulation looks much better, but I'll let a
native speaker have another check.
Some comments: I preferred the previous example id because it's not obvious
what \042\047 is. And a bullet list would be less heavyweight
R. David Murray added the comment:
Cleanup on test failure is supposed to be done. Cleanup on crash or buildbot
timeout isn't done as far as I know (and that was a concern I had with the
changes made to support.TESTFN and the cwd, but I didn't articulate it very
well).
If you find tests
New submission from Jeremy Kloth:
This patch incorporates Tcl/Tk/Tix into the MSVC build in the same fashion as
OpenSSL has been done.
Highlights:
- A new project, tcltk, is added that simply calls the Python script
build_tkinter.py to build the externals.
- New helper module
Chris Jerdonek added the comment:
Here is a proposed patch.
One note on the patch. I feel the second sentence of the note is worth adding
because value.__format__() departs from what PEP 3101 says:
Note for Python 2.x: The 'format_spec' argument will be either
a string object or a unicode
Steve Newcomb added the comment:
I preferred the previous example id because it's not obvious what
\042\047 is.
Yeah, but the example I wrote has an in-pattern backreference and a real reason
to use one.
In the attached patch, I have changed [\042\047] to [\'\]. That's certainly
clearer
Chris Jerdonek added the comment:
To clarify, one of the sentences above should have read, I feel the second
sentence of the note *in the patch* was worth adding... (not the second
sentence of the PEP note I quoted).
--
___
Python tracker
Chris Jerdonek added the comment:
To follow up on David's comment, the unit tests in the test suite aren't
consistent in their treatment of temp directories (e.g. they don't use a common
API or code path). So it may be hard to address this globally short of wiping
the entire temp directory
Vitaly added the comment:
Nothing, except that there are probably other places in the stdlib
where we can get bitten by this bug. Note that this should eventually
be done for another reason, see http://bugs.python.org/issue15918
For greatest benefit, I think that the work-around should be
Felipe Cruz added the comment:
Updated based on Pitrou comments
--
Added file: http://bugs.python.org/file27220/issue15744_v2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15744
___
Richard Oudkerk added the comment:
You would need to call memory_release(). Perhaps we can just expose it on the
C-API level as PyMemoryView_Release().
Should PyMemoryView_Release() release the _PyManagedBufferObject by doing
mbuf_release(view-mbuf) even if view-mbuf-exports 0?
Doing
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15903
___
___
Python-bugs-list
Antoine Pitrou added the comment:
So I think the combination of PyMemoryView_FromObject() with a call to
PyMemoryView_Release() should indeed work here.
I don't think we want to expose a mutable bytes object to outside code, so IMO
PyMemoryView_FromMemory() is preferrable.
--
New submission from STINNER Victor:
If it is not too late, I would like to fix the name of two functions of the
new faulthandler module before the release of Python 3.3 final. Changes:
* dump_tracebacks_later() = dump_traceback_later()
* cancel_dump_tracebacks_later() =
Stefan Krah added the comment:
Richard Oudkerk rep...@bugs.python.org wrote:
Should PyMemoryView_Release() release the _PyManagedBufferObject by doing
mbuf_release(view-mbuf) even if view-mbuf-exports 0?
No, I think it should really just be a wrapper:
diff --git a/Objects/memoryobject.c
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15969
___
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15967
___
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
title: AT_FDCWD is 0xffd19553 on Solaris 10,resulting in compiler warnings.
- AT_FDCWD is 0xffd19553 on Solaris 10, resulting in compiler warnings.
___
Python tracker
Changes by Amaury Forgeot d'Arc amaur...@gmail.com:
--
assignee: - docs@python
nosy: +docs@python
stage: committed/rejected - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15956
Stefan Krah added the comment:
Antoine Pitrou rep...@bugs.python.org wrote:
I don't think we want to expose a mutable bytes object to outside code,
so IMO PyMemoryView_FromMemory() is preferrable.
I agree, but PyMemoryView_FromMemory(PyBytes_AS_STRING(b), n, PyBUF_WRITE)
just hides the fact
Changes by Andrew Svetlov andrew.svet...@gmail.com:
--
nosy: +asvetlov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15956
___
___
Changes by STINNER Victor victor.stin...@gmail.com:
--
versions: +Python 3.4 -Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8425
___
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15964
___
___
Python-bugs-list
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15954
___
___
Python-bugs-list
Antoine Pitrou added the comment:
Antoine Pitrou rep...@bugs.python.org wrote:
I don't think we want to expose a mutable bytes object to outside code,
so IMO PyMemoryView_FromMemory() is preferrable.
I agree, but PyMemoryView_FromMemory(PyBytes_AS_STRING(b), n, PyBUF_WRITE)
just hides
Richard Oudkerk added the comment:
Are we talking about a big speedup here or could we perhaps just keep
the existing code?
I doubt it is worth the hassle. But I did want to know if there was a clean
way to do what I wanted.
--
___
Python
Changes by Mark Dickinson dicki...@gmail.com:
--
nosy: +brian.curtin
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15966
___
___
Python-bugs-list
Christian Heimes added the comment:
I think this might be related to #15923. It shouldn't be necessary to rebuild
the AST definition unless you have modified the grammar and AST files.
--
nosy: +christian.heimes
___
Python tracker
Changes by Brian Curtin br...@python.org:
--
assignee: - bquinlan
nosy: +bquinlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15966
___
___
STINNER Victor added the comment:
python: ../../src/xcb_io.c:273: poll_for_event: Assertion
`!xcb_xlib_threads_sequence_lost' failed.
I get a similar XCB assertion error:
xcb_io.c:221: poll_for_event: Assertion `(((long) (event_sequence) - (long)
(dpy-request)) = 0)' failed.
The problem is
STINNER Victor added the comment:
Perhaps the three new macros should be made available in a .h file?
Good idea. Maybe pymacros.h? These macros need to be documented (with a comment
in the .h file)
--
nosy: +haypo
___
Python tracker
STINNER Victor added the comment:
See also #15964.
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15923
___
___
Python-bugs-list
Changes by STINNER Victor victor.stin...@gmail.com:
--
components: +Tests, Tkinter -XML
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13888
___
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15964
___
Antoine Pitrou added the comment:
The patch looks ok to me. At least passing fn as keyword arg should be fixed.
Passing self as keyword arg admittedly sounds a bit awkward.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
All my slaves' /tmp's are polluted with regrtest fluff.
Which regrtest fluff exactly?
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15967
Julian Berman added the comment:
It's slightly less confusing -- Where do I patch is the question that will
never go away, and the fact that you don't have the `sys` module imported is a
small hint that you should be doing patch(mymodule.sys, path) not
patch(sys.path). Also, the fact that
Michael Foord added the comment:
Well, people vote with their code and find mock.patch vastly more useful than
patch.object...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11664
___
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +cjerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7712
___
___
Python-bugs-list
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
assignee: - ezio.melotti
nosy: +ezio.melotti
type: - behavior
versions: +Python 2.7, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15304
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +ezio.melotti, flox
type: - enhancement
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15415
___
R. David Murray added the comment:
I actually agree with Julian here. I much prefer patch.object and do my best
to avoid mock.patch. support.patch is also equivalent to patch.object and not
patch. That doesn't change the fact that other people prefer mock.patch, of
course.
I think
Julian Berman added the comment:
With all due respect, your response pretty much ignored mine completely. That's
OK, I've agreed with you that patch seems more common.
I'll point you additionally though to the fact that Éric's original post also
used patch.object's semantics, as does
Chris Jerdonek added the comment:
What about patch_object()?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11664
___
___
Python-bugs-list
Chris Jerdonek added the comment:
Attached is a proposed patch.
Some explanation behind the patch that stems from the above comments:
The following is an example of Formatter.format() returning str in the current
implementation that would break if we made Formatter.format() return unicode
Ezio Melotti added the comment:
IMHO a setattr-like API seems the obvious choice here, so that's what I would
expect. I haven't used mock, so I wasn't familiar with mock.patch, but after
skimming through the mock docs a bit I think I have to agree with Julian and
RDM.
In addition, I'm not
Ezio Melotti added the comment:
I think I'm -1 on this, for the following reasons:
* it's less explicit;
* it gives you less control (I'm thinking e.g. at the () added by
:func:/:meth: but not :class:, so that :func:`int` and :class:`int` are
rendered in different ways);
* even though this
Roundup Robot added the comment:
New changeset 974a4cae6094 by Trent Nelson in branch 'default':
#15965: Explicitly cast AT_FDCWD as (int).
http://hg.python.org/cpython/rev/974a4cae6094
--
nosy: +python-dev
___
Python tracker rep...@bugs.python.org
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +haypo
stage: needs patch - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7665
___
Changes by Trent Nelson tr...@snakebite.org:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15965
___
Ezio Melotti added the comment:
re.compile seems twice as fast as pickle.loads:
import re
import pickle
import timeit
N = 10
s = r = re.compile('[\\udc80-\\udcff]')
t = timeit.Timer(s, 'import re')
print(%6.2f - re.compile % t.timeit(number=N))
s = r = pickle.loads(p)
p =
Nick Coghlan added the comment:
The particular app that is getting affected is clearing out and rebuilding the
logging configuration without restarting in response to a notification that the
application config has changed. This was working OK on 2.6, but started
misbehaving when ported to
New submission from Joshua Biagio:
There seems to be a very minor bug in the ElementTree.py file, for the
so-called 'empty' elements that are serialized without a closing tag. The
HTML_EMPTY tuple/set is used to lookup these tags.
In the Lib/xml/etree/ElementTree.py file, the HTML_EMPTY tuple
New submission from Ezio Melotti:
Seen on
http://buildbot.python.org/all/builders/AMD64%20Lion%203.x/builds/428/steps/test/logs/stdio
==
FAIL: test_dump_tracebacks_later_file (test.test_faulthandler.FaultHandlerTests)
Changes by Julian Berman julian+python@grayvines.com:
--
nosy: +Julian
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7559
___
___
Roundup Robot added the comment:
New changeset 3498ffd3cdee by Ezio Melotti in branch '2.7':
#15970: xml.etree.ElementTree now serializes correctly the empty HTML elements
meta and param.
http://hg.python.org/cpython/rev/3498ffd3cdee
New changeset 17c528cff63f by Ezio Melotti in branch '3.2':
Ezio Melotti added the comment:
Fixed, thanks for the report!
--
assignee: - ezio.melotti
nosy: +ezio.melotti
resolution: - fixed
stage: - committed/rejected
status: open - closed
type: - behavior
versions: -Python 2.6, Python 3.1
___
Python
1 - 100 of 102 matches
Mail list logo
