Antoine Pitrou added the comment:
Reusing MANPAGER is practical. Yet another PY* environment variable doesn't
seem warranted in this case.
Agreed with Alexander's simpler logic proposal in msg105153.
--
nosy: +pitrou
___
Python trac
Changes by Antoine Pitrou :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue11136>
___
___
Python-bugs-list mailing list
Unsubscri
Antoine Pitrou added the comment:
I would rather make _thread.error an alias of RuntimeError. That way, we can
reconcile the docs and the code without breaking compatibility.
Also, importing _thread won't be necessary to catch errors raised in threading
objects.
--
Antoine Pitrou added the comment:
Ok, clarified in r88371. Thank you!
--
nosy: +pitrou
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.1
___
Python tracker
<http://bug
Antoine Pitrou added the comment:
> aaugustin added the comment:
>
> I agree with your solution. Unfortunately, I do not know how you would
> redefine ThreadError to extend RuntimeError in a C extension.
>
> _thread.error is created line 741 in trunk/Modules/threadmodul
Antoine Pitrou added the comment:
> Any interest in a cleaned up version of the Debian patch (remove
> double opt, line length, add documentation for overriding BASECFLAGS
> and OPT)?
I think it would be nice, but it should have a test if possible.
Otherwise there'll keep bei
Antoine Pitrou added the comment:
Committed in r88377, thank you!
--
nosy: +pitrou
resolution: accepted -> fixed
stage: -> committed/rejected
status: open -> closed
versions: -Python 3.3
___
Python tracker
<http://bugs.python.or
Changes by Antoine Pitrou :
--
assignee: -> ronaldoussoren
components: +Macintosh
nosy: +ned.deily, ronaldoussoren
___
Python tracker
<http://bugs.python.org/issu
Changes by Antoine Pitrou :
--
components: +Interpreter Core
nosy: +jyasskin
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issue11147>
___
___
Changes by Antoine Pitrou :
--
nosy: +benjamin.peterson
___
Python tracker
<http://bugs.python.org/issue11145>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
This is a duplicate of issue10115.
--
nosy: +pitrou
resolution: -> duplicate
status: open -> closed
superseder: -> Support accept4() for atomic setting of flags at socket creation
___
Python track
Antoine Pitrou added the comment:
Duplicated in issue11157.
--
nosy: +mmarkk
___
Python tracker
<http://bugs.python.org/issue10115>
___
___
Python-bugs-list m
Changes by Antoine Pitrou :
--
nosy: +vinay.sajip
___
Python tracker
<http://bugs.python.org/issue11158>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Thanks for doing this. Looking at the patch: Modules/_io/_iomodule.h has macros
for dealing with off_t (it also defines Py_off_t for Windows), perhaps you want
to use them.
Also, support.unlink() takes care of ignoring ENOENT for you.
Regardling the sizes
Antoine Pitrou added the comment:
I agree with barry's argument and also with Marc-André's argument on
python-ideas. Your directories are far cleaner than before with pyc files all
around, so what is the problem exactly?
--
nos
Antoine Pitrou added the comment:
> I left the off_t handling as is (it seems to work on *nix testing).
> Perhaps someone can handle the Windows side?
Ok, after looking at the code, it appears Windows already should have proper
handling of 64-bit sizes under 32-bit
Changes by Antoine Pitrou :
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue11163>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> PyThread_acquire_lock_timed
It's on purpose that I didn't document this one. I'm not sure the PyThread_
APIs should be used by third-party extensions; so I'd prefer to hear about
potential users before starting documentin
Antoine Pitrou added the comment:
> Antoine: do you think it's worth the effort?
As mentioned above, the readline 6 compatibility code was checked in.
The ClassType expansion is 2.x-only, so probably can't go in since it's a
feature request.
What remains is the filename
Antoine Pitrou added the comment:
> Are you suggesting to use pthread_atfork to call pthread_mutex_init on > all
> mutexes created by Python in the child after a fork? I'll have to > ponder
> that some more. Given the mutexes are all useless post fork it > does no
Antoine Pitrou added the comment:
Le jeudi 10 février 2011 à 17:03 +, STINNER Victor a écrit :
> STINNER Victor added the comment:
>
> Le jeudi 10 février 2011 à 16:41 +, Ross Lagerwall a écrit :
> > Ross Lagerwall added the comment:
> >
> > 32-bit compu
Antoine Pitrou added the comment:
Hmm. I'm not sure passing a list of platforms is a good idea. People may want
to write e.g. "'bsd' in platform". Also, there are a lot of platforms we don't
have access to, so we can't actually maintain a list of platforms.
Changes by Antoine Pitrou :
--
assignee: -> tarek
components: +Distutils, Distutils2 -Installation
nosy: +barry, eric.araujo, tarek
stage: -> patch review
versions: +Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
> As for test_ttk and such, those that have a third-party dependency are
> still optional no matter what. This change is **only** for modules we
> expect to always build on certain platfoms (e.g., winreg under Windows
> or crypt on UNIX systems).
Antoine Pitrou added the comment:
> Well, ctypes failing because it cannot compile is only when a platform
> that is not listed as optional cannot import it. So if some platform
> does not support ctypes then it gets added to the list, end of story.
How do you add "llvm under d
Antoine Pitrou added the comment:
Your "versionchanged" is misleading. It should be something like "family and
type can now be omitted".
--
components: +Library (Lib)
nosy: +pitrou
stage: -> patch review
type: -> feature request
Changes by Antoine Pitrou :
--
nosy: +pitrou, sable
___
Python tracker
<http://bugs.python.org/issue11172>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
components: +Library (Lib)
nosy: +r.david.murray
stage: -> patch review
type: -> behavior
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
The part which is replaced by that patch (the readline() method in IMAP4_SSL)
doesn't exist anymore in current imaplib code. Instead the file-like object
created by socket.makefile() is used; its readline() method is probably quite
faster than any
Antoine Pitrou added the comment:
The patch works fine on Linux but breaks test_pipes and test_sqlite on
Windows:
[1/1] test_pipes
testBadAppendOptions (test.test_pipes.SimplePipeTests) ... ok
testBadOpenMode (test.test_pipes.SimplePipeTests) ... ok
testBadPrependOptions
New submission from Antoine Pitrou :
The ccbench shipped with 3.2 is supposed to work with older versions but:
Traceback (most recent call last):
File "/home/antoine/py3k/py3k/Tools/ccbench/ccbench.py", line 609, in
main()
File "/home/antoine/py3k/py3k/Tools/ccbench/cc
Antoine Pitrou added the comment:
> Python's "configure.in" script typically requires a specific version of >
> autoconf. At the moment, this reads:
> version_required(2.61)
This is a bit outdated. Right now we only have:
AC_PREREQ(2.65)
which IIUC means 2.6
Changes by Antoine Pitrou :
--
priority: high -> normal
stage: -> needs patch
type: crash -> behavior
versions: -Python 3.1
___
Python tracker
<http://bugs.python.or
New submission from Antoine Pitrou :
pyOpenSSL (*) has the good idea of defining exception subclasses for the
various OpenSSL error codes (ZeroReturnError, WantReadError, etc.). The ssl
module could do the same.
(*) http://packages.python.org/pyOpenSSL/openssl-ssl.html
--
components
Antoine Pitrou added the comment:
Hmm, strange. Is it a 32-bit build? Is HAVE_LARGEFILE_SUPPORT defined in
pyconfig.h?
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue11
Antoine Pitrou added the comment:
Apparently AIX needs a specific #define to enable large file support:
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.genprogc/doc/genprogc/prg_lrg_files.htm
Python defines _LARGEFILE_SOURCE by default
Antoine Pitrou added the comment:
Hmm, interesting. Can you post the results of the two following snippets:
>>> f = open('foo', 'wb')
>>> f.seek(2**32)
# should be 4294967296
>>> f = open('foo&
Antoine Pitrou added the comment:
Thanks for the patch.
> The test fails in a different way now:
> [...]
> IOError: [Errno 27] File too large
This seems to mean that your file system isn't configured for large
files. According to
http://publib.boulder.ibm.com/infocenter/pseries/
Antoine Pitrou added the comment:
Yes, I think the skipping code in test_largefile should be factored out and
used both in test_io and test_largefile (to be honest I don't know why test_io
has large file tests as well; perhaps I should merge them together).
--
stage: -> patc
Antoine Pitrou added the comment:
> is it OK if I open a new issue for each broken unit test on AIX even
> if I have not investigated them at the moment?
Yes. That way they get recorded somewhere and other people can chime in.
If you plan to investigate them you can add a sentence say
Changes by Antoine Pitrou :
--
nosy: +giampaolo.rodola
___
Python tracker
<http://bugs.python.org/issue11192>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Perhaps related to the test_locale failure in issue11190.
--
nosy: +haypo, pitrou
___
Python tracker
<http://bugs.python.org/issue11
Changes by Antoine Pitrou :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue11188>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
This is a potential crasher.
It would also be nice if you listed those cases where Python assumes signed
overflow behaviour. Can you open a separate issue for that?
--
nosy: +mark.dickinson, pitrou
priority: normal -> high
versions: +Python
Changes by Antoine Pitrou :
--
nosy: +georg.brandl
___
Python tracker
<http://bugs.python.org/issue11200>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Actually, looks like distribute should be updated to include "abiflags" in
self.config_vars in setuptools/command/easy_install.py. There seems to be a
whole bunch of code pasted directly from distutils and it isn't up-to-date
anymore.
Changes by Antoine Pitrou :
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue11201>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
components: +Library (Lib) -IO
nosy: +tarek
___
Python tracker
<http://bugs.python.org/issue11202>
___
___
Python-bugs-list mailin
Antoine Pitrou added the comment:
Intuitively, this seems rather normal to me. If I move a file under Unix, I
don't expect its access rights or ownership to change. "Move" really means what
it means: you have to update its permission explicitly if that's what you need
(s
Antoine Pitrou added the comment:
First comments:
- secure_connection() should be named ssl_something() like other
methods. ssl_start() perhaps?
- in ssl_shutdown():
+elif err.args[0] == ssl.SSL_ERROR_SSL:
+pass
SSL_ERROR_SSL doesn't exist. Perhap
Antoine Pitrou added the comment:
> According to the shutil doc page, neither copy or copy2 should do
> this. And since they do, and you say shutil.move is implemented using
> shutil.copy2, shouldn't files moved with shutil.move also then inherit
> the permissions?
There'
Antoine Pitrou added the comment:
> Ok.
>
> But that makes the whole method inconsistent.
>
> Basically, if it's on the same filesystem, rename the file, and thus
> not inheriting ACL. If it's on another use copy2, and inherit ACL.
I think you're misundersta
Antoine Pitrou added the comment:
> On my system (Win Server 2008 R2 64-Bit, Python 2.7.1), when I use
> copy, copy2 or move(to another filesystem), the file _will_ get the
> ACL of the DST folder, and remove any ACL in SRC file that the DST
> folder does not have.
>
> Thus,
Changes by Antoine Pitrou :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue11202>
___
___
Python-bugs-list mailing list
Unsubscri
Antoine Pitrou added the comment:
Hello,
> I spent today some time to rewrite `memoryobject.c`, and cleaning up
> the Py_buffer handling in it. (I wrote also the Numpy PEP 3118
> implementation, so this was straightforward to do.)
Thanks for trying this.
> - Rewritten memoryobjec
Antoine Pitrou added the comment:
> The problem in the current way is that the structure sent to
> `bf_releasebuffer` does not contain the same data as what was filled
> in by `bf_getbuffer`, and since the contents are dup-ed,
> `bf_releasebuffer` is called multiple times with t
Antoine Pitrou added the comment:
> > Hmm, there's a misunderstanding. bf_releasebuffer is called exactly
> > once for each call to bf_getbuffer.
>
> Wrong: http://bugs.python.org/issue7433
This is a different issue.
> static int
> memory_getbuf(PyMemoryViewObjec
Antoine Pitrou added the comment:
> dup_buffer does *dst = *src, which overwrites the view.internal
> pointer obtained from one GetBuffer call with a pointer obtained from
> a previous one.
Ah, ok, then it deserves fixing.
--
___
Pytho
Changes by Antoine Pitrou :
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue11205>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> - For each buffer yielded by `bf_getbuffer`, `bf_releasebuffer`
> is called exactly once.
>
> Each `bf_releasebuffer` call is guaranteed to get the same
> view->internal pointer as filled in previously by the
> corres
Antoine Pitrou added the comment:
> Problems remain. Suppose `bf_getbuffer` for memoryview is implemented
> so that it returns a view exported by the original object (and not the
> memoryview). Consider an example:
>
> >>> obj = PictureSet() # exposes
Antoine Pitrou added the comment:
That said:
> Having the memoryview "own" the exported buffer would be a simple
> solution to the above issue.
If you can implement that without exhibing the issues we discussed above (e.g.
O(N) memory consumption when doing repetitive slicin
Antoine Pitrou added the comment:
> I'm still not comfortable with a convention that relies on *clients*
> of the PEP 3118 API not mucking with the internals of the Py_buffer
> struct.
Which clients? Those who export the buffer, or those who consume it?
> I'm *much*
Antoine Pitrou added the comment:
Judging from the traceback, you should probably report that issue to numpy
instead.
--
nosy: +pitrou
resolution: -> invalid
status: open -> pending
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
> >> I'm *much* happier with the rule based on malloc/free semantics where
> >> the *pointer* passed to PyObject_GetBuffer must match a single later
> >> call to PyObject_ReleaseBuffer.
> >
> > Agreed that Py_buffe
Antoine Pitrou added the comment:
I don't see why we would provide an option to replace a magic number with
another magic number. I find it strange that AIX doesn't simply enable
unbounded virtual address spaces.
(by "unbounded" I mean "bounded by CPU limitation
New submission from Antoine Pitrou :
Just to test that auto-nosy works.
--
assignee: tarek
components: Distutils2
messages: 128559
nosy: alexis, eric.araujo, pitrou, tarek
priority: normal
severity: normal
status: open
title: distutils2 test issue
versions: 3rd party
Antoine Pitrou added the comment:
Ok, works fine!
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Changes by Antoine Pitrou :
--
nosy: +giampaolo.rodola
___
Python tracker
<http://bugs.python.org/issue11214>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
This looks vaguely similar to http://bugs.python.org/issue6236#msg91007,
although the latter has been fixed.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue11
Antoine Pitrou added the comment:
> We could change the option to become:
> --with-aix-maxdata=value
> where value could be between 0 and 8, with a default at 0 (nothing
> passed to the compiler).
Doesn't LDFLAGS work for that? I don't think we want a lot of
platform-spec
Antoine Pitrou added the comment:
Was fixed in r85656 by Martin (in 3.2), but needs backporting.
--
assignee: -> loewis
nosy: +loewis, pitrou
stage: needs patch -> committed/rejected
versions: -Python 3.2
___
Python tracker
Changes by Antoine Pitrou :
--
nosy: +loewis, mhammond
___
Python tracker
<http://bugs.python.org/issue11210>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Agreed.
--
___
Python tracker
<http://bugs.python.org/issue941346>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue941346>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> LDFLAGS will apply it to all the shared libraries which is not really
> what we want.
Is there a downside?
--
___
Python tracker
<http://bugs.python.org/i
Changes by Antoine Pitrou :
--
nosy: +georg.brandl
___
Python tracker
<http://bugs.python.org/issue730467>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> can you take a look at issue 730467?
Yes, this is in my bug queue. But unless Georg decides otherwise, this will go
in after 3.2 is released (in 3.2.1 probably).
--
___
Python tracker
<http://bugs.pyth
Antoine Pitrou added the comment:
> > I've committed a patch which does just this (in r85422). Hopefully it
> > won't break anything.
>
> Could I convince you to patch 2.7 as well?
It was backported in r86848. This means it
Antoine Pitrou added the comment:
I get an error using the following curl too:
curl 7.20.1 (x86_64-mandriva-linux-gnu) libcurl/7.20.1 OpenSSL/1.0.0a
zlib/1.2.3 libidn/1.18 libssh2/1.2.5
Protocols: dict file ftp ftps http https imap imaps ldap ldaps pop3 pop3s rtsp
scp sftp smtp smtps telnet
Antoine Pitrou added the comment:
Georg, the non-abiflags portion seems to need backporting.
--
assignee: -> georg.brandl
priority: release blocker -> normal
status: closed -> open
___
Python tracker
<http://bugs.python.org
Changes by Antoine Pitrou :
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue11222>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
We have the same issue on our FreeBSD 6.4 buildbot:
http://python.org/dev/buildbot/all/builders/x86%20FreeBSD%203.x/builds/1216/steps/test/logs/stdio
(FreeBSD 7.2 is fine)
Can you tell me what the values of _POSIX_SEMAPHORES and HAVE_SEM_TIMEDWAIT are
(or
Antoine Pitrou added the comment:
Ok, the problem is when the condition variable-based implementation is chosen
in Python/thread_pthread.h.
It is actually reproduceable under Linux by adding `#undef USE_SEMAPHORES` just
after `#define USE_SEMAPHORES`.
The problem is that, contrary to
Antoine Pitrou added the comment:
Here is a patch that makes the test fail rather than hang. Sébastien, can you
try it out?
--
keywords: +patch
title: test_threadsignals.py hanging on AIX -> interruption of locks by signals
not guaranteed when the semaphore implementation is not u
Changes by Antoine Pitrou :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue8844>
___
___
Python-bugs-list
Changes by Antoine Pitrou :
--
resolution: -> duplicate
status: open -> closed
superseder: -> interruption of locks by signals not guaranteed when the
semaphore implementation is not used
___
Python tracker
<http://bugs.python.or
Changes by Antoine Pitrou :
--
nosy: +db3l
___
Python tracker
<http://bugs.python.org/issue11223>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> I have other tests locking semi-randomly on AIX 5.3 and/or AIX 6.1,
> like test_socket and test_io. That may be related.
Which test cases exactly?
--
___
Python tracker
<http://bugs.python.org/i
Changes by Antoine Pitrou :
--
nosy: +georg.brandl
___
Python tracker
<http://bugs.python.org/issue11184>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> Well I don't know precisely:
>
> * when running make buildbottest, test_socket will systematically hang
> on AIX 5.3 and 6.1.
>
> * but when running ./python -Wd -E -bb Lib/test/test_socket.py, the
> tests complete rather quickly
Antoine Pitrou added the comment:
Assuming it doesn't break other platforms, I'm fine with it.
--
___
Python tracker
<http://bugs.python.org/issue11184>
___
__
Changes by Antoine Pitrou :
--
type: resource usage -> performance
___
Python tracker
<http://bugs.python.org/issue11224>
___
___
Python-bugs-list mai
Changes by Antoine Pitrou :
--
nosy: +giampaolo.rodola
___
Python tracker
<http://bugs.python.org/issue11227>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Could you open another issue? (or post in issue 11185 above)
--
___
Python tracker
<http://bugs.python.org/issue11223>
___
___
Changes by Antoine Pitrou :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue11230>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +georg.brandl
___
Python tracker
<http://bugs.python.org/issue10709>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
David, I think you attached your patch to the wrong issue.
Sébastien, according to the IBM docs, the memory limit can be changed using the
LDR_CNTRL variable, so running the test suite shouldn't need special linker
flags, or?
(also, wouldn't it be
Antoine Pitrou added the comment:
> I think people may be more interested in setting permanently the
> maximum memory that can be allocated by python rather than using an
> environment variable that may be lost and which impacts all the
> applications.
Agreed, but it
Antoine Pitrou added the comment:
> 3) bytes(bytes_or_buffer) -> immutable copy of bytes_or_buffer
> 4) bytes(memory_view) -> bytes
These are AFAIR the same.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python
3701 - 3800 of 16792 matches
Mail list logo
