Antoine Pitrou added the comment:
Closing as fixed, since nothing strange seems to have appeared so far.
--
resolution: accepted -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Changes by Antoine Pitrou :
--
assignee: pitrou ->
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue2281>
___
___
Python-bugs-list mai
Antoine Pitrou added the comment:
All of them should probably raise io.UnsupportedOperation instead (which
inherits from both IOError and ValueError).
--
___
Python tracker
<http://bugs.python.org/issue7
Antoine Pitrou added the comment:
The portability API is now available (see Include/pytime.h).
--
___
Python tracker
<http://bugs.python.org/issue8844>
___
___
Changes by Antoine Pitrou :
--
assignee: -> michael.foord
___
Python tracker
<http://bugs.python.org/issue9587>
___
___
Python-bugs-list mailing list
Unsubscri
Antoine Pitrou added the comment:
The expression "largefile support" is a bit misleading. What it simply does is
that it uses "long long" instead of "long" in order to store and compute file
offsets. But, since a long is wide enough on your system to hold a
Changes by Antoine Pitrou :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue9548>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
About wchar2char:
- PEP 383 says “With this PEP, non-decodable bytes >= 128 will be represented
as lone surrogate codes U+DC80..U+DCFF. Bytes below 128 will produce
exceptions”. Your patch accepts bytes below 128.
- I don't understand why you decreme
Antoine Pitrou added the comment:
This is a variant of the kind of annoyance pointed out in #9548. Here, it seems
addbuilddir() in Lib/site.py shouldn't import sysconfig, because it imports the
re module.
--
nosy: +pitrou
___
Python tracker
Antoine Pitrou added the comment:
Here is a patch which works if the patch in #9548 is also applied.
It won't work alone because opening a file in text mode currently imports
locale which imports re, etc. ... all before adding the build dir to sys.path.
Of course, since the log
Antoine Pitrou added the comment:
Here is a C version of addbuilddir. It solves the present issue.
--
Added file: http://bugs.python.org/file18509/c-addbuildir.patch
___
Python tracker
<http://bugs.python.org/issue9
Antoine Pitrou added the comment:
U+0085 corresponds to a line terminator (*). and codecs.open() observes this
convention.
Do note that the new io.open() (or the built-in open() in 3.x) only recognizes
'\r' and '\n' as line separators.
In any case, changing this b
Antoine Pitrou added the comment:
The patch doesn't check that instantiating these methods work at all.
--
nosy: +benjamin.peterson, pitrou
stage: -> patch review
versions: +Python 3.2 -Python 3.1
___
Python tracker
<http://bugs
Antoine Pitrou added the comment:
> Is there any way to get the efficiency of codecs I/O readlines()
> chunking behavior and specify a list of characters to use? Can the
> file delimiter be changed in python as in perl?
No, but you can use readlines() from the standard open() functi
Antoine Pitrou added the comment:
I've committed a patch in r83986. I will watch the buildbots and close if
everything's fine.
--
assignee: -> pitrou
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> pending
Antoine Pitrou added the comment:
Thank you. I'm not an ABC expert but it looks ok. Guido, what do you think?
--
nosy: +gvanrossum
___
Python tracker
<http://bugs.python.org/i
Changes by Antoine Pitrou :
--
nosy: pitrou
priority: normal
severity: normal
status: open
title: PC/getpathp.c unused?
___
Python tracker
<http://bugs.python.org/issue9
New submission from Antoine Pitrou :
PC/getpathp.c claims it is “Used by DOS, OS/2, Windows 3.1, Windows 95/98,
Windows NT”, but Modules/getpath.c already tries to be cross-platform. It is
not obvious whether the former is used at all.
--
components: Interpreter Core
messages: 113839
Changes by Antoine Pitrou :
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue9595>
___
___
Python-bugs-list
Changes by Antoine Pitrou :
--
resolution: wont fix -> duplicate
superseder: -> test_heapq: AttributeError: 'int' object has no attribute 'pop'
___
Python tracker
<http:
Antoine Pitrou added the comment:
I've committed an updated version of the C patch in r83988, after Victor's
comments on IRC.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> pending
___
Py
Changes by Antoine Pitrou :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue9203>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Antoine Pitrou :
--
assignee: -> pitrou
status: pending -> open
___
Python tracker
<http://bugs.python.org/issue9589>
___
___
Python-bugs-list
Changes by Antoine Pitrou :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue9589>
___
___
Python-bugs-list mailing list
Unsubscri
Antoine Pitrou added the comment:
Oh, my bad. Is there any reason for the MS_WINDOWS guards in Modules/getpath.c,
then?
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Changes by Antoine Pitrou :
--
nosy: +giampaolo.rodola
___
Python tracker
<http://bugs.python.org/issue9601>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> For example, on the x64 machine the following dict() mapping
> 10,000,000 very short unicode keys (~7 chars) to integers eats 149
> bytes per entry.
This is counting the keys too. Under 3.x:
>>> d = {}
>>> for i in range(
Antoine Pitrou added the comment:
So, here is the modified benchmark. It first creates a cache of the random
wordlist, because it is quite long to compute (for N up to 1000). The cache
is reused in subsequent runs. This takes some memory though (probably won't run
it if you have
Antoine Pitrou added the comment:
Your patch threatens to break compatibility. I think it would be better to
simply change the "encoding" and "errors" attributes of standard streams.
--
___
Python tracker
<http://bu
Antoine Pitrou added the comment:
I don't think we should change anything in 2.7 at this point. It risks breaking
compatibility while we are at the end of the 2.x line, for little added benefit
(the old buffer API has always been insecure with mutable buffers).
As fo
Antoine Pitrou added the comment:
> Can we close this issue, or do you consider that it is still very
> important to not load too much modules at startup?
The patch eases the bootstrap constraints by creating a
bootstrap-friendly subset of locale.py. It is indeed much less pressing
no
Changes by Antoine Pitrou :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue1739648>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue9605>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue9604>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue9603>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
-.. function:: getaddrinfo(host, port, family=0, socktype=0, proto=0, flags=0)
+.. function:: getaddrinfo(host, port[, family[, type[, proto[, flags)
You should keep using the new documentation convention, that is:
.. function:: getaddrinfo(host, port
Changes by Antoine Pitrou :
--
nosy: +benjamin.peterson
___
Python tracker
<http://bugs.python.org/issue5996>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +benjamin.peterson
___
Python tracker
<http://bugs.python.org/issue9607>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Two nits:
- bug fixes shouldn't have a "versionadded" or "versionchanged" entry (it's
only for new features)
- Misc/NEWS should be in antichronological order
--
nosy: +pitrou
___
Antoine Pitrou added the comment:
> Added a patch that adds support for recomputing the timeout, plus a test for
> it.
>
> Can this still make it into 3.2, or is it too disruptive at this point
> in the release process?
No problem at this point, we're not yet in beta pha
Antoine Pitrou added the comment:
> Is freeing the memory allocated for setvbuf() while close() running in
> another thread really safe?
I don't know. I guess nobody does that.
--
___
Python tracker
<http://bugs.python
Changes by Antoine Pitrou :
--
nosy: +doko
___
Python tracker
<http://bugs.python.org/issue8449>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
The patch looks fine code-wise, but it also needs a doc addition in
Doc/library/abc.rst.
--
___
Python tracker
<http://bugs.python.org/issue5
Changes by Antoine Pitrou :
--
nosy: +richard
___
Python tracker
<http://bugs.python.org/issue9610>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Antoine Pitrou :
Modules/_io/fileio.c assumes that read() and write() allow a Py_ssize_t length,
but under Windows the length is an int, limiting chunk size to 2GB.
It should be easy enough to read or write in multiple chunks, although testing
might be difficult
Antoine Pitrou added the comment:
Created #9611 to report the FileIO 64-bit issue under Windows.
--
___
Python tracker
<http://bugs.python.org/issue9566>
___
___
New submission from Antoine Pitrou :
None of these warnings look critical (one affects the "search finger"
optimization of pop(), one affects the result from __length_hint__ on set
iterators, and the other the hash value of frozensets without any obviously bad
consequences), but
Antoine Pitrou added the comment:
Created #9612 for the mostly harmless warnings in the set implementation.
--
___
Python tracker
<http://bugs.python.org/issue9
Antoine Pitrou added the comment:
The zlib warnings are genuine and there's a specific bug for 64-bitness of
zlibmodule.c: #8650.
--
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
os.write() (in posixmodule.c) is also affected. os.read(), however, is limited
to 32-bit inputs.
--
___
Python tracker
<http://bugs.python.org/issue9
New submission from Antoine Pitrou :
Under 64-bit Windows, Python aliases PyLong_FromPid() to PyLong_FromLong() (and
PyLong_AsPid() to PyLong_AsLong()), but a C "long" is 32-bit, while apparently
the MSVCRT defines a pid to be intptr_t, that is 64-bit. A potential loss of
d
Changes by Antoine Pitrou :
--
nosy: +brian.curtin, tim.golden
___
Python tracker
<http://bugs.python.org/issue9611>
___
___
Python-bugs-list mailing list
Unsub
Antoine Pitrou added the comment:
Opened #9613 for 64-bitness of process ids.
--
___
Python tracker
<http://bugs.python.org/issue9566>
___
___
Python-bugs-list m
New submission from Antoine Pitrou :
A number of legitimate warnings get emitted under a 64-bit Windows build (in
many places, _pickle uses ints or longs instead of "Py_ssize_t" variable to
store various lengths and sizes):
1>..\Modules\_pickle.c(284) : warning C4244: '=&
Antoine Pitrou added the comment:
Opened #9614 for the _pickle issues (which look quite legitimate).
--
___
Python tracker
<http://bugs.python.org/issue9
Antoine Pitrou added the comment:
The write() man page says:
The number of bytes written may be less than count if, for example,
there is insufficient space on
the underlying physical medium, or the RLIMIT_FSIZE resource limit is
encountered (see setrlimit(2)),
or the
Antoine Pitrou added the comment:
> > Most people use buffered I/O, and the buffered layer automatically retries.
>
> I see. I think this is already slightly problematic: if you send an
> interrupt, it won't oblige. IMO, any such loop ought to be
> interruptable.
Well,
Antoine Pitrou added the comment:
Le dimanche 15 août 2010 à 18:53 +, Martin v. Löwis a écrit :
> Martin v. Löwis added the comment:
>
> > Well, the loop stops when an error status is returned by the raw IO
> > layer. At that point, the buffered IO layer re-raises
New submission from Antoine Pitrou :
This is what I get when MSVC 2008 tries to build the _ssl module:
8>-- Build started: Project: _ssl, Configuration: Debug x64 --
8>Performing Pre-Build Event...
8>'""' is not recognized as an internal or external command
Antoine Pitrou added the comment:
There is also a similar warning for deque iterators' __length_hint__ (line 1124
in _collectionsmodule.c).
--
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
> Try setting HOST_PYTHON.
It worked, thank you.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.o
New submission from Antoine Pitrou :
Prompted by Martin in #9611, here is a patch fixing the new buffered IO layer
so that an incoming signal during a successful partial write() doesn't get
ignored. Tests included.
--
components: IO
files: sigbufio.patch
keywords: patch
mes
Antoine Pitrou added the comment:
Another possibility is to do the check in the FileIO object instead. Both
approaches give the same results for standard file descriptor IO.
--
___
Python tracker
<http://bugs.python.org/issue9
New submission from Antoine Pitrou :
Recently there have been test_ssl freezes on the buildbots. They seem to happen
in the asyncore test case:
http://www.python.org/dev/buildbot/builders/i386%20Ubuntu%203.x/builds/1903/steps/test/logs/stdio
http://www.python.org/dev/buildbot/builders/x86
Antoine Pitrou added the comment:
Actually, this can be reproduced by running test_smtpd before test_ssl:
$ ./python -m test.regrtest -v -uall test_smtpd test_ssl
It then freezes at that point:
[...]
test_asyncore_server (test.test_ssl.ThreadedTests)
Check the example asyncore integration
Antoine Pitrou added the comment:
> does test_smtpd register file descriptor 0 (stdin) in asyncore?
After some debug prints, it turns out to be the case.
One general problem is asyncore's global socket_map, which means it can leak
between tests if some tests fail cleaning correct
Antoine Pitrou added the comment:
In r84086, I've added a save/restore guard of asyncore.socket_map to the
regression test suite. It also warns when a test fails to leave the socket_map
in its initial test. test_smtpd is the only test that displays the wa
Antoine Pitrou added the comment:
Adding new "global" objects looks a bit complicated. Why not simply update all
thread-local objects when the "global" flag is set?
--
nosy: +pitrou
___
Python tracker
<http://bu
Antoine Pitrou added the comment:
> Good question. Is that simple to do? I didn't think to look if there
> were a central list of all python TLS states.
There's a linked list from the current interpreter state, which in turn
can be got from the current thread state (see I
Antoine Pitrou added the comment:
Well, given that both replies (expected and actual) are in the 25x category,
and that (according to the RFC) “the third digit gives a finer gradation of
meaning in each of the function categories, specified by the second digit”,
perhaps practicality beats
New submission from Antoine Pitrou :
longobject.h uses SIZEOF_SOCKET_T:
#if SIZEOF_SOCKET_T <= SIZEOF_LONG
#define PyLong_FromSocket_t(fd) PyLong_FromLong((SOCKET_T)(fd))
#define PyLong_AsSocket_t(fd) (SOCKET_T)PyLong_AsLong(fd)
#else
#define PyLong_FromSocket_t(fd) PyLong_FromLongL
Antoine Pitrou added the comment:
This is witnessed in MSVC warning messages such as:
2>..\Modules\socketmodule.c(1611) : warning C4244: 'function' : conversion from
'SOCKET_T' to 'long', possible loss of data
--
Antoine Pitrou added the comment:
We don't need a separate header file, the definitions can go into pyport.h
instead.
--
nosy: +brian.curtin, pitrou, tim.golden
versions: +Python 2.7 -Python 3.3
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
However, since this makes SOCKET_T public, it should probably be renamed to
Py_SOCKET_T.
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue4
Antoine Pitrou added the comment:
This is now fixed in r84146 (py3k) and r84151 (3.1). I've made the "hash" field
a Py_ssize_t, consistently with the dict implementation.
--
resolution: -> fixed
status: open -> closed
___
Antoine Pitrou added the comment:
> I'm not sure whether backporting it to 3.1 is a good idea. It's
> potentially an ABI change (although a minor one, as the field offsets
> remain the same, only the interpretation of the padding may change).
Well, it is unlikely that
Antoine Pitrou added the comment:
After trying it out, pulling SOCKET in the Python headers brings complications
under Windows, because you need to include which in turn breaks
compilation of _pickle.c (duplicate definition of "FLOAT", "INT", etc.).
An alternative
Antoine Pitrou added the comment:
Here is a patch implementing the approach I proposed above.
It successfully removes warnings about casting SOCKET to long under 64-bit
Windows.
--
Added file: http://bugs.python.org/file18557/sockdefine.patch
Antoine Pitrou added the comment:
For the record, there is now a C API function (PyThreadState_SetAsyncExc()) to
raise an asynchronous exception on a Python thread, although the signature is
bizarre (it takes the thread id rather than the thread state structure itself).
--
nosy
Antoine Pitrou added the comment:
Modified patch committed in r84155 (py3k). Thanks for your contribution!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bug
Changes by Antoine Pitrou :
--
nosy: +brian.curtin, tim.golden
___
Python tracker
<http://bugs.python.org/issue9433>
___
___
Python-bugs-list mailing list
Unsub
Antoine Pitrou added the comment:
> Why is PyLong_FromSocket_t defined in a header file in the first
> place? The only caller is in socketmodule.c, and calling it elsewhere
> wouldn't work, anyway, since it relies on SOCKET_T being defined.
I agree, but it was already like that
Antoine Pitrou added the comment:
Ok, I've committed the change in r84176 (py3k) and r84178 (2.7). Thank you!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http:
Antoine Pitrou added the comment:
We already have an optional timeout on threading.Thread.join(), which I suppose
means that people need/want that feature.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue9
Antoine Pitrou added the comment:
I don't have a Solaris machine to test, but the patch is straightforward
enough. I've committed it in r84179. Thank you!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status
Antoine Pitrou added the comment:
> I do not agree with Antoine. For binary transfer, another method is
> called, and it does work fine. However, storelines would be called
> for ASCII mode, in which encoding and decoding should be done by the
> FTP program. ASCII mode would tra
Antoine Pitrou added the comment:
I'm not sure in what way the error is inappropriate. Python simply propagates
whatever errno the C library sets on failure.
As for the comment that connect() shouldn't be called twice, this was fixed in
2.6 by r60101.
--
nosy: +pitrou
Antoine Pitrou added the comment:
Well, that's what BytesWarning is for. I agree it is annoying in normal use,
but it is meant to ease porting of 2.x code. That's why it is only enabled when
you use the corresponding command-line switch.
The warning in the dict case is especially
Antoine Pitrou added the comment:
> That way, if _HTTP_DEFAULT_TIMEOUT is never set, it will use the the
> socket timeout. Admittedly I'd rather see all uses of module globals go
> away, but I think this would be a good compromise.
Why not provide {httplib,urllib}.{set,get}
Antoine Pitrou added the comment:
> It's worth noting that this warning is dependent on hash() producing
> the same values for 'equivalent' bytes and str instances. This seems
> a bit fragile, and is something that could potentially change in the
> future---with byte
Antoine Pitrou added the comment:
I think the bytearray special-casing should be removed. Otherwise one can
reallocate the buffer in another thread while it is being used for decoding.
--
nosy: +pitrou
versions: -Python 2.7
___
Python tracker
Antoine Pitrou added the comment:
> Doesn't the GIL protect the bytearray buffer? Or does decoding free the GIL?
Well, decoding can call arbitrary Python code and therefore, yes,
release the GIL.
Ironically, PyUnicode_Decode() itself (called from
PyUnicode_FromEncodedObject()) fills
Antoine Pitrou added the comment:
It turns out, quite expectedly, that distutils doesn't reuse the various
LDFLAGS recorded by sysconfig (why are there three of them?), but instead only
uses LDSHARED:
>>> sysconfig.get_config_var('LDSHARED'
Antoine Pitrou added the comment:
Following patch works here. I've added XXX tags in strange places.
--
keywords: +patch
Added file: http://bugs.python.org/file18598/m32.patch
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
Ok, there is also a failure in test_sysconfig (the patch makes no difference):
==
FAIL: test_ldshared_value (test.test_sysconfig.TestSysConfig
Antoine Pitrou added the comment:
It appears that 2.7 has the same issue, although fewer tests fail (apparently
not all 3.2 tests have been backported).
--
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issue9
Changes by Antoine Pitrou :
--
priority: high -> release blocker
title: test_distutils failure with -m32 -> can't build extensions with
non-default ldflags (e.g. -m32)
___
Python tracker
<http://bugs.python
Antoine Pitrou added the comment:
Ping?
--
___
Python tracker
<http://bugs.python.org/issue9251>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Antoine Pitrou :
Here is a test for multi-threaded circular imports (in order to exercise the
import lock), following a comment by Graham Dumpleton on #9260.
--
components: Tests
files: circulartest.patch
keywords: patch
messages: 114541
nosy: brett.cannon, ncoghlan
Antoine Pitrou added the comment:
This new patch takes the reverse approach and makes the function definitions
(PyLong_FromSocket_t() and PyLong_AsSocket_t()) private to socketmodule.h. I
will commit if no-one objects.
--
Added file: http://bugs.python.org/file18601/sockdefine2.patch
1301 - 1400 of 16792 matches
Mail list logo
