On Thursday 11 November 2010 21:02:43 Antoine Pitrou wrote:
> On Thu, 11 Nov 2010 20:44:52 +0100
>
> "Martin v. Löwis" wrote:
> > > How do you support cross-platform code using bytes filenames?
> > > IIRC, it has already been argued that it was an important feature. Many
> > > filesystem-related
On Thursday 11 November 2010 20:50:35 you wrote:
> > Even if I hate the MBCS encoding, because it replaces undecodable
> > characters by similar glyphs by default, I'm not certain that it is a
> > good idea to drop the bytes API. Can it be a problem to port programs
> > from Python2 to Python3? Do
On Saturday 13 November 2010 17:21:37 you wrote:
> On 2010/11/12 4:26, Victor Stinner wrote:
> > On Thursday 11 November 2010 17:07:28 Hirokazu Yamamoto wrote:
> >> Hello. Is it possible to remove Win32 ANSI API (ie: GetFileAttributesA)
> >> and only use Win32 WIDE
Hi,
On Friday 19 November 2010 17:53:58 Alexander Belopolsky wrote:
> I was recently surprised to learn that chr(i) can produce a string of
> length 2 in python 3.x.
Yes, but only on narrow build. Eg. Debian and Ubuntu compile Python 3.1 in
wide mode (sys.maxunicode == 1114111).
> I suspect tha
On Friday 19 November 2010 23:25:03 you wrote:
> > Python is unclear about non-BMP characters: narrow build was called
> > "ucs2" for long time, even if it is UTF-16 (each character is encoded to
> > one or two UTF-16 words).
>
> No, no, no :-)
>
> UCS2 and UCS4 are more appropriate than "narrow"
On Thursday 02 December 2010 19:06:51 georg.brandl wrote:
> Author: georg.brandl
> Date: Thu Dec 2 19:06:51 2010
> New Revision: 86934
>
> Log:
> #7475: add (un)transform method to bytes/bytearray and str, add back codecs
> that can be used with them from Python 2.
Oh no, someone did it. Was it
On Friday 03 December 2010 16:11:29 R. David Murray wrote:
> > >>> 'abc'.transform('hex')
> > TypeError: 'str' does not support the buffer interface
> >
> > >>> b'abc'.transform('rot13')
> > TypeError: expected an object with the buffer interface
>
> I find these 'buffer interface' error messages
On Saturday 04 December 2010 09:31:04 you wrote:
> Alexander Belopolsky writes:
> > In fact, once the language moratorium is over, I will argue that
> > str.encode() and byte.decode() should deprecate encoding argument and
> > just do UTF-8 encoding/decoding. Hopefully by that time most people
Hi,
In 2008, I proposed a patch to raise a Python exception on SIGSEVG
signal. In some cases, it's possible to catch the exception, log it, and
continue the execution. But because in some cases, the Python internal
state is corrupted, the idea was rejected (see the issue #3999).
Someone aske
Le 18/12/2010 13:21, Georg Brandl a écrit :
I very much like having a traceback on (some) segmentation faults,
Why do you say "some" segmentation faults?
but it's clear there needs to be a way to turn it off. An environment variable
seems to be the obvious choice (for the reasons you stated fo
Le dimanche 19 décembre 2010 à 19:53 +0100, "Martin v. Löwis" a écrit :
> There should be at least one reviewer with an established track record
> of being interested/knowledgable in the POSIX APIs and cross-platform
> aspects of it.
Functions used by the fault handler:
- write()
- PyUnicode_Che
Le samedi 18 décembre 2010 à 17:23 +0100, Georg Brandl a écrit :
> Well, without a closer I assume that for some crashes it's just not
> possible anymore for the Python interpreter to even print out the
> traceback?
The worst case occurs if the frame objects are corrupted, eg. if the
filename of a
Le samedi 18 décembre 2010 à 13:55 -0500, Alexander Belopolsky a écrit :
> I am -1 on the feature as written. I would be -0 if it did not
> install signal handlers by default and even better was implemented in
> a separate module, not in core.
I think that the feature is useless if it is disabled
Le dimanche 19 décembre 2010 à 20:20 +0100, Antoine Pitrou a écrit :
> Can you clarify why you think those signal handlers fall into that
> description? After all, SIGINT, SIGILL and friends only get triggered in
> catastrophic conditions.
SIGSEGV, not SIGINT
Victor
_
Le samedi 18 décembre 2010 à 08:50 -0500, James Y Knight a écrit :
> I think instead of calling abort() to kill the process, you should:
> - install the signal handler with SA_NODEFER|SA_RESETHAND (or if sigaction is
> not present, explicitly reset the action to SIG_DFL and unblock first thing
>
Le lundi 20 décembre 2010 à 00:02 +0100, Victor Stinner a écrit :
> Another possible approach is to restore the previous handler in the
> fault handler, and don't call abort(). The fault should occur again, and
> so the previous signal handler will be called.
I implemented this simp
Le lundi 20 décembre 2010 à 02:05 +0100, "Martin v. Löwis" a écrit :
> The problem is that merely being POSIX compliant would not be enough
> to allow calling a function in a signal handler. Instead, the function
> *also* needs to be async-signal safe.
Yes, this issue was fixed in an older version
Le lundi 20 décembre 2010 12:08:35, Stefan Krah a écrit :
> I think the output is not particularly informative:
>
> $ ./python Lib/test/crashers/gc_inspection.py
> (, , , , , ,
> , , , ) Fatal Python error: Segmentation fault
>
> Traceback (most recent call first):
> File "Lib/test/crashers/gc_
Le lundi 20 décembre 2010 08:22:40, vous avez écrit :
> >> Looking at your function list, my other concern is that you are calling
> >> Python API without holding the GIL, IIUC. In particular, you are
> >> accessing _PyThreadState_Current, which may not point to the current
> >> thread if the curre
Le lundi 20 décembre 2010 15:55:57, Stefan Krah a écrit :
> > The backtrace is valid. Don't you think that this backtrace is more
> > useful than just "Segmentation fault"?
>
> Perhaps I misunderstood, but I thought the purpose of the patch was to
> let developers act more quickly on bug reports.
Le lundi 20 décembre 2010 12:08:35, Stefan Krah a écrit :
> Another test is hanging indefinitely (Ubuntu 64-bit):
>
> $ ./python Lib/test/crashers/nasty_eq_vs_dict.py
> [hanging with no output]
Oh, I understood. I always test with Python compiled using --with-pydebug.
With pydebug, a segfault oc
Le lundi 20 décembre 2010 18:22:48, Alexander Belopolsky a écrit :
> On Mon, Dec 20, 2010 at 11:56 AM, Stefan Krah wrote:
> > Victor Stinner wrote:
> ..
>
> >> The fault handler helps developers because they don't have to have a
> >> Python compiled in debu
Hi,
Thanks to all your useful remarks, I improved my patch twice (version 10
and 11). I think that the last version (11) addresses all reported
issues. The most notable change is that the fault handler is now
disabled by default. It fixes also the function getting the thread
state, it now works in
Le lundi 20 décembre 2010 à 13:09 -0500, Alexander Belopolsky a écrit :
> What if the program crashes (again) in the signal handler before
> having a chance to restore registers?
If the fault handler crashs, the registers are not restored.
> Also, can you point to documentation that describes reg
Le jeudi 23 décembre 2010 à 03:37 +0100, "Martin v. Löwis" a écrit :
> > So, do you agree with the fault handler? Does someone want to give a
> > last review because I commit it?
>
> It's a new feature, so regardless of whether it's correct or not
> (which I haven't reviewed yet), I don't think it
Le jeudi 23 décembre 2010 à 21:59 +0100, Georg Brandl a écrit :
> this thread showed that it is not at all obvious how the feature should look
> like
Ok, I understand. I closed #8863 (rejected) and I created a third party
module on the Python cheese shop:
http://pypi.python.org/pypi/faulthandler/
Le jeudi 23 décembre 2010 à 22:58 +, Martin (gzlist) a écrit :
> On 23/12/2010, Victor Stinner wrote:
> >
> > I tested my patch on Windows (XP), Ubuntu (10.4) and FreeBSD (8) and it
> > works correctly: all tests pass and the system fault handler (Windows
> > popu
Le vendredi 24 décembre 2010 à 12:59 +, Michael Foord a écrit :
> I hope you will include it in 3.3 though; it is great functionality.
I don't know, Python 3.3 is not planned yet. Anyway, faulthandler is
already available and you can use it on Python 2.5 through 3.2.
> I would really like to
Le dimanche 26 décembre 2010 à 14:10 +, exar...@twistedmatrix.com a
écrit :
> On 25 Dec, 10:31 pm, mer...@netwok.org wrote:
> >>faulthandler is a module: enable the handler is simple as "import
> >>faulthandler".
> >
> >That sounds like a source of unwanted behavior (aka problems) if the
> >han
Le lundi 27 décembre 2010 à 22:22 +0100, Georg Brandl a écrit :
> Am 27.12.2010 21:12, schrieb victor.stinner:
> > Author: victor.stinner
> > Date: Mon Dec 27 21:12:13 2010
> > New Revision: 87518
> >
> > Log:
> > Issue #10778: decoding_fgets() decodes the filename from the filesystem
> > encoding
(oops, I posted an incomplete message, stupid mailer)
Le lundi 27 décembre 2010 à 22:22 +0100, Georg Brandl a écrit :
> Am 27.12.2010 21:12, schrieb victor.stinner:
> > Author: victor.stinner
> > Date: Mon Dec 27 21:12:13 2010
> > New Revision: 87518
> >
> > Log:
> > Issue #10778: decoding_fgets(
Le lundi 27 décembre 2010 à 23:13 -0500, R. David Murray a écrit :
> > Modified: python/branches/py3k/Doc/c-api/unicode.rst
> > ==
> > --- python/branches/py3k/Doc/c-api/unicode.rst (original)
> > +++ python/branches/p
Le lundi 27 décembre 2010 à 23:07 -0500, R. David Murray a écrit :
> On Mon, 27 Dec 2010 02:49:27 +0100, victor.stinner
> wrote:
> > Author: victor.stinner
> > Date: Mon Dec 27 02:49:26 2010
> > New Revision: 87504
> >
> > Log:
> > Issue #9738: Document encodings of error and warning functions
Le mardi 28 décembre 2010 à 10:12 +0100, Georg Brandl a écrit :
> >> > Author: victor.stinner
> >> > Date: Mon Dec 27 21:12:13 2010
> >> > New Revision: 87518
> >> >
> >> > Log:
> >> > Issue #10778: decoding_fgets() decodes the filename from the filesystem
> >> > encoding instead of UTF-8.
> >
>
Le mardi 28 décembre 2010 à 11:40 +0100, "Martin v. Löwis" a écrit :
> Am 28.12.2010 11:28, schrieb Victor Stinner:
> > Le lundi 27 décembre 2010 à 23:07 -0500, R. David Murray a écrit :
> >> On Mon, 27 Dec 2010 02:49:27 +0100, victor.stinner
> >> wrote:
&g
Le mardi 28 décembre 2010 à 15:22 -0500, Terry Reedy a écrit :
> On 12/28/2010 8:26 AM, victor.stinner wrote:
> > Author: victor.stinner
> > Date: Tue Dec 28 14:26:42 2010
> > New Revision: 87537
> >
> > Log:
> > Issue #10783: struct.pack() doesn't encode implicitly unicode to UTF-8
>
> > Modified
Le mardi 28 décembre 2010 à 12:14 -0500, R. David Murray a écrit :
> I think your first paragraph is what you should put in the docs: "it is
> best to pass only ASCII-encoded strings, but the function interprets
> the input string as ISO-8859-1 if it contains non-ASCII characters".
Nice, done in r
Hi,
FreeBSD 7.2 3.x buildbot is red since some weeks (or months?) because of
a concurrent.futures failure. The problem is that
test_concurrent_futures uses many (multiprocessing) POSIX semaphores,
whereas POSIX semaphores support in FreeBSD is recent and limited. We
have to use SysV semaphores (ft
Le mercredi 29 décembre 2010 à 21:04 +0100, Antoine Pitrou a écrit :
> Doesn't it suggest a possible resource leak somewhere?
I already checked that: all locks are destroyed correctly on each test.
- test_all_completed_some_already_completed() uses 51 SemLock objects
- test_first_completed() us
Le mercredi 29 décembre 2010 à 21:49 +0100, "Martin v. Löwis" a écrit :
> Of course, one may wonder why test_first_completed manages
> to create 41 SemLock objects, when all it tries to do is two future
> calls.
More numbers (on Linux):
- Queue: 3 SemLock
- Condition: 4 SemLock
- Event: 5 SemL
Le jeudi 30 décembre 2010 à 17:05 +0100, "Martin v. Löwis" a écrit :
> > I really don't think it is our job to maintain a list of OS/versions
> > which work and don't work.
>
> Of course not. I would propose a dynamic test: check how many POSIX
> semaphores the installation supports, and fail if i
Le mercredi 29 décembre 2010 à 14:20 +0100, "Martin v. Löwis" a écrit :
> Am 28.12.2010 18:08, schrieb Lukas Lueg:
> > Also, the
> > load_fast in lne 22 to reference x could be taken out of the loop as x
> > will always point to the same object
>
> That's not true; a debugger may change the va
Hi,
In the PEP , I read:
--
import os, sys
enc, esc = sys.getfilesystemencoding(), 'surrogateescape'
def wsgi_string(u):
# Convert an environment variable to a WSGI "bytes-as-unicode"
string
return u.encode(enc, esc).decode('iso-8859-1')
def run_with_cgi(application):
Le mardi 04 janvier 2011 à 13:20 +0100, Antoine Pitrou a écrit :
> On Tue, 04 Jan 2011 03:44:53 +0100
> Victor Stinner wrote:
> > def wsgi_string(u):
> > # Convert an environment variable to a WSGI "bytes-as-unicode"
> > string
> > retu
Le mercredi 05 janvier 2011 à 23:48 -0500, Alexander Belopolsky a
écrit :
> I would be happy with just
>
>if accept2dyear:
>if 69 <= y <= 99:
>y += 1900
>elif 0 <= y <= 68:
>y += 2000
># call system function with tm_year = y - 1900
Perfect. That's w
Le jeudi 06 janvier 2011 à 00:10 -0500, Alexander Belopolsky a écrit :
> If calling specific system functions such as strftime with tm_year <
> 0 is deemed unsafe, we can move the check to where the system function
> is called.
What do you mean by "unsafe"? Does it crash? On my Linux box,
strftim
Le jeudi 06 janvier 2011 à 10:47 -0500, R. David Murray a écrit :
> On Thu, 06 Jan 2011 12:55:24 +0100, Victor Stinner
> wrote:
> >Le jeudi 06 janvier 2011 à 00:10 -0500, Alexander Belopolsky a écrit :
> >> If calling specific system functions such as strftime with tm_ye
Le jeudi 06 janvier 2011 à 23:50 +, And Clover a écrit :
> On Tue, 2011-01-04 at 03:44 +0100, Victor Stinner wrote:
> > What is this horrible encoding "bytes-as-unicode"?
>
> It is a unicode string decoded from bytes using ISO-8859-1. ISO-8859-1
> is the encoding s
Le vendredi 07 janvier 2011 à 16:39 +0100, phillip.eby a écrit :
> Author: phillip.eby
> Date: Fri Jan 7 16:39:27 2011
> New Revision: 87815
>
> Log:
> More bytes I/O fixes
>
>
> Modified:
>peps/trunk/pep-.txt
>
> Modified: peps/trunk/pep-.txt
>
Le vendredi 14 janvier 2011 à 02:32 +0200, anatoly techtonik a écrit :
> It is already 2011. I didn't monitor the issue closely, but judging by
> the face that http://bugs.python.org/issue9527 is still open, Python
> still doesn't have a method to extract current timezone information
> from system.
Hi,
I just closed issue #4953 just before Python 3.2 final: the CGI module
should now handle correctly binary files and Unicode. I also patched
urllib.parse.parse_qs() and urllib.parse.parse_qsl() to add encoding and
errors arguments.
Please test the CGI module (with Python 3.2) as much as possib
) and
PyUnicode_FromFormat() doesn't need a buffer size (no risk of buffer
overflow). I suppose that it makes Python faster, but I didn't try.
(*) Python 3.2 doesn't support non-ASCII in the module *name*, only in
the path (sys.path).
Victor Stinner
Le mercredi 19 janvier 2011 à 10:42 -0800, Brett Cannon a écrit :
> > I am not sure what exactly is not supported. On my OSX system:
>
> Victor said this is a Windows-specific issue.
Autoquote: "(a) (...) doesn't work with a locale encoding different than
UTF-8"
Hum, it's not exactly the locale
Le mercredi 19 janvier 2011 à 13:38 -0500, Alexander Belopolsky a
écrit :
> PEP 3131 does not distinguish between different types of identifiers,
> so I think it assumes that non-ascii module names should be supported.
My opinion is that we should suport non-ASCII module names and
unencodable path
Le mercredi 19 janvier 2011 à 12:19 -0800, Glenn Linderman a écrit :
> Since Python allows non-ASCII variable names, I think it should allow
> non-ASCII module names also, on any platform that supports the
> appropriate characters in the filesystem.
>
> Since some platforms already accept them,
Le mercredi 19 janvier 2011 à 15:44 -0800, Toshio Kuratomi a écrit :
> Additionally, many unix filesystem don't specify a filesystem encoding for
> filenames; they deal in legal and illegal bytes which could lead to
> troubles. This problem of which encoding to use is a problem that can be
> seen
Le mercredi 19 janvier 2011 à 18:07 -0800, Toshio Kuratomi a écrit :
> Saying that multiple encodings on a single system is a misconfiguration
> every time it comes up does not make it true.
Yes, each filesystem can have its own encoding. For example, this is
supported by Linux. Python doesn't sup
Le mercredi 19 janvier 2011 à 20:39 -0800, Toshio Kuratomi a écrit :
> Teaching students to write non-portable code (relying on filesystem encoding
> where your solution is, don't upload to pypi anything that has non-ascii
> filenames) seems like the exact opposite of how you'd want to shape a youn
t møøse.bites
>
> (Required extensive work by Victor Stinner in :issue:`9425`.)
Ooops, it is not the good example :-) In this example, møøse is not a
module path, but a module name... And Python 3.2 doesn't support
correctly non-ASCII module names on all operating systems yet (see
"[
Le jeudi 20 janvier 2011 à 10:04 +0100, raymond.hettinger a écrit :
> +Some operating systems allow direct access to the unencoded bytes in the
> +environment. If so, the :attr:`os.supports_bytes_environ` constant will be
> +true.
> +
> +For direct access to unencoded environment variables (if ava
Hi,
It looks like some people fear that non-ASCII module names will cause
troubles for the interoperability: you can try my patch attached to
issue #3080 to prevent these issues and fix all bugs :-)
http://bugs.python.org/issue3080
I should maybe create a dummy Python project using non-ASCII mod
Le samedi 22 janvier 2011 à 13:25 -0500, Alexander Belopolsky a écrit :
> > zipimport uses ASCII encoding instead of *cp497* to decode filenames, ..
>
> Shouldn't this be "instead of *cp437*"?
Woops, correct: fixed in r88145.
Victor
___
Python-Dev mai
Le dimanche 23 janvier 2011 à 19:18 +0100, "Martin v. Löwis" a écrit :
> > Adding an extra set of quotes around the command seems to fix
> > this. I've attached a patch.
Hey! I already wrote exactly the same patch! But I didn't propose it
upstream because I was unable to reproduce the bug.
>
Le lundi 24 janvier 2011 11:35:22, Stephen J. Turnbull a écrit :
> ... VFAT-formatted file systems and Shift JIS file names ...
I missed something: VFAT stores filenames as unicode (whereas FAT only
supports byte filenames). Well, VFAT stores filenames twice: as a 8+3 byte
strings and as a 255 u
Le lundi 24 janvier 2011 16:39:39, Victor Stinner a écrit :
> Le lundi 24 janvier 2011 11:35:22, Stephen J. Turnbull a écrit :
> > ... VFAT-formatted file systems and Shift JIS file names ...
>
> I missed something: VFAT stores filenames as unicode (whereas FAT only
> suppo
Le lundi 24 janvier 2011 à 19:26 -0800, Toshio Kuratomi a écrit :
> Why not locale:
> * Relying on locale is simply not portable. (...)
> * Mixing of modules from different locales won't work. (...)
I don't understand what you are talking about.
When you import a module, the module name becomes a
Hi,
Le mardi 25 janvier 2011 à 18:07 -0800, Brett Cannon a écrit :
> This broke the buildbots (R. David Murray thinks you may have
> forgotten to call super() in the 'payload is None' branch). Are you
> getting code reviews and fully running the test suite before
> committing? We are in RC.
> (...
Le mercredi 26 janvier 2011 à 11:12 +0100, "Martin v. Löwis" a écrit :
> There are cases where there is no real "transfer", in the sense in which
> you are using the word. For example, with NFS, you can access the very
> same file simultaneously on two systems, with no file name conversion
> (unles
Le mercredi 26 janvier 2011 à 08:24 -0500, James Y Knight a écrit :
> On Jan 26, 2011, at 4:40 AM, Victor Stinner wrote:
> > During
> > Python 3.2 development, we tried to be able to use a filesystem encoding
> > different than the locale encoding (PYTHONFSENCODING environme
Hi,
Antoine Pitrou noticed that Python 3.2 tries a lot of filenames to load
a module:
http://bugs.python.org/issue11051
Python 3.1 does already test many filenames, but with Python 3.2, it is
even worse.
For each directory in sys.path, it tries 9 suffixes: '',
'.cpython-32m.so', 'module.cpython-
Le dimanche 30 janvier 2011 à 22:52 +1000, Nick Coghlan a écrit :
> On Sun, Jan 30, 2011 at 7:25 PM, Georg Brandl wrote:
> >> And why it does test with and without "module".
> >
> > Because it always did (there's a thing called backwards compatibility.)
> >
> > This is of course probably the obvio
Hi,
Since the end of last december, I'm still working on my fault handler
project:
https://github.com/haypo/faulthandler
You can use it to get more information after a crash or if you program
hangs somewhere. It helps if you don't have access to other debugging
tool (eg. install gdb7+python-gdb.p
Le jeudi 03 février 2011 à 12:22 -0500, Reid Kleckner a écrit :
> On Thu, Feb 3, 2011 at 8:05 AM, Victor Stinner
> wrote:
> > - SIGABRT is not handled
>
> Why not?
Just because I forgot to handle it. But I don't know if it is a good
thing to display the Python back
Le jeudi 10 février 2011 à 16:19 +0100, M.-A. Lemburg a écrit :
> > And the following were added to 3.2,
> > of which only 2 are documented:
> >
> > PyArg_ValidateKeywordArguments
> > PyAST_CompileEx
> > Py_CompileString
> > Py_CompileStringExFlags
> > PyErr_NewExceptionWithDoc(documented)
> >
Le jeudi 10 février 2011 à 17:25 +, Mark Shannon a écrit :
> What about this one then,
>
> PyFrame_GetLineNumber was added because people were using
> PyCode_Addr2Line to get the current line number.
>
> The API will contain then both
> PyFrame_GetLineNumber *and* PyCode_Addr2Line.
> The API
Le vendredi 11 février 2011 à 14:52 +0100, Giampaolo Rodolà a écrit :
> >> New Revision: 88395
> >>
> >> Log:
> >> asyncore: introduce a new 'closed' attribute to make sure that dispatcher
> >> gets closed only once.
> >> In different occasions close() might be called more than once, causing
> >>
Le lundi 14 février 2011 à 07:40 +0100, Georg Brandl a écrit :
> On behalf of the Python development team, I'm happy to announce
> the third release candidate of Python 3.2.
Oh, the RC3 changelog is still very long. And sorry, because I
contributed to this long list of changes! I hope that the lis
Le mardi 15 février 2011 à 09:30 +0100, "Martin v. Löwis" a écrit :
> I'm going to perform a Debian upgrade of svn.python.org on Friday,
> between 9:00 UTC and 11:00 UTC. I'll be disabling write access during
> that time. The outage shouldn't be longer than an hour.
It's time to move to Mercurial!
Le mercredi 16 février 2011 à 14:05 -0500, Barry Warsaw a écrit :
> On Feb 16, 2011, at 12:34 PM, Terry Reedy wrote:
>
> >I would like the next release called 3.2.0 rather than just 3.2.
>
> +1
>
> (I'd have said +0 for the humor of it :).
Should we write +1.0, +1.3 or just +1? Mark can
Le dimanche 20 février 2011 à 23:22 +0100, Georg Brandl a écrit :
> On behalf of the Python development team, I'm delighted to announce
> Python 3.2 final release.
>
> Python 3.2 is a continuation of the efforts to improve and stabilize the
> Python 3.x line.
Congratulation to all Python develope
Le 21/02/2011 22:55, antoine.pitrou a écrit :
Author: antoine.pitrou
Date: Mon Feb 21 22:55:48 2011
New Revision: 88484
Log:
Issue #10826: Prevent sporadic failure in test_subprocess on Solaris due
to open door files.
if __name__ == "__main__":
-print(','.join(str(fd) for fd in range(
You should maybe backport this fix to Python 3.2.
Le mardi 22 février 2011 à 20:24 +0100, giampaolo.rodola a écrit :
> Author: giampaolo.rodola
> Date: Tue Feb 22 20:24:33 2011
> New Revision: 88505
>
> Log:
> In FTP.close() method, make sure to also close the socket object, not only
> the file.
Le mercredi 23 février 2011 à 08:35 +0100, Georg Brandl a écrit :
> This commit introduced tabs, at least in dynload_dl.c.
WHAT? No, I didn't introduced new tabs: dynload_dl.c always used tabs.
Anyway, I converted tabs to spaces in r88527.
Victor
___
Le jeudi 03 mars 2011 à 11:06 +0200, Sümer Cip a écrit :
> While porting a C extension from 2 to 3, I realized that there are some
> general cases which can be automated. For example, for my specific
> application (yappi - http://code.google.com/p/yappi/), all I need to do is
> following things:
S
Hi,
Some months ago, I proposed a patch to display the Python backtrace on a
segfault. The API was not stable, it was too for Python 3.2, and it was
enabled by default. I wrote a module instead of a patch so it can be
used on any version of Python, and it has a better API. And now I would
like to
Le vendredi 04 mars 2011 à 21:10 +1000, Nick Coghlan a écrit :
> > Some months ago, I proposed a patch to display the Python backtrace on a
> > segfault. The API was not stable, it was too for Python 3.2, and it was
> > enabled by default. I wrote a module instead of a patch so it can be
> > used o
Le vendredi 04 mars 2011 à 06:32 -0500, Scott Dial a écrit :
> On 3/4/2011 6:10 AM, Nick Coghlan wrote:
> > On Fri, Mar 4, 2011 at 10:58 AM, Victor Stinner
> > wrote:
> >> So, what do you think?
> >
> > Something we may want to consider is enabling it by defau
Hi,
Does the bug tracker will continue to support rX links after the
migration to Mercurial?
Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/o
Le vendredi 04 mars 2011 à 15:05 +0200, Simon Cross a écrit :
> While I like this module I'm against it going into the standard
> library so soon. Modules need time to mature, develop and gain wide
> adoption outside the standard library where they are less constrained
> by maintaining compatibilit
Le vendredi 04 mars 2011 à 10:05 -0600, s...@pobox.com a écrit :
> Is Rietveld or Review Board being used within the Python core development
> community? I looked at the dev guide but didn't see anything obvious about
> code reviews. I don't see how to search the Rietveld instance at
> codereview
Le lundi 07 mars 2011 à 10:05 +0100, Éric Araujo a écrit :
> Hi,
>
> > Author: victor.stinner
> > Date: Wed Mar 2 02:03:14 2011
> > New Revision: 88709
> > Log: Issue #8923: cache str.encode() result
> >
> > When a string is encoded to UTF-8 in strict mode, the result is cached into
> > the
> >
Le lundi 14 mars 2011 à 15:36 -0400, David Bolen a écrit :
> Antoine Pitrou writes:
>
> > I suggest you try http://code.google.com/p/bbreport/, which provides a
> > very nice command-line interface.
>
> Speaking of bbreport, I sometimes use the published page on that site
> (http://code.google.c
Le lundi 21 mars 2011 à 04:09 +0100, "Martin v. Löwis" a écrit :
> Since Python 2.5, we maintain two versions of PyArg_ParseTuple:
> one outputting int; the other one outputting Py_ssize_t.
>
> The former should have been removed in 3.0, but this was forgotten.
>
> Still, I would like people to m
Le lundi 21 mars 2011 à 15:35 +0100, Stefan Behnel a écrit :
> Victor Stinner, 21.03.2011 15:21:
> > Le lundi 21 mars 2011 à 04:09 +0100, "Martin v. Löwis" a écrit :
> >> Since Python 2.5, we maintain two versions of PyArg_ParseTuple:
> >> one outputting int
Le mercredi 23 mars 2011 à 22:58 +1000, Nick Coghlan a écrit :
> There are several ways to get unbuffered IO back in a cross-platform
> manner, but efficient codec operation means working that way by
> default would be a really bad idea. Users may *say* they prefer
> convenience over speed, but tha
Le mercredi 23 mars 2011 à 22:58 +1000, Nick Coghlan a écrit :
> There are several ways to get unbuffered IO back in a cross-platform
> manner, ...
Oh, by the way: TextIOWrapper doesn't support unbuffered mode. Only
fully buffered and line buffered modes. So print("Test", end='') doesn't
display i
Hi,
If nobody complains, I plan to push my faulthandler module into Python
3.3 in one week. It's a module to display the Python backtrace on a
segfault, on a user signal or after a timeout.
I opened an issue (#11393) for that, 3 weeks ago, and I already got some
interesting comments. I fixed some
Le jeudi 24 mars 2011 à 01:05 +0100, "Martin v. Löwis" a écrit :
> > What is the procedure to add a new module? Just add the code into
> > Modules and patch setup.py? The module is distributed under the BSD
> > (2-clause) license.
>
> Also add it to the Visual Studio build process. It either needs
Le mercredi 23 mars 2011 à 20:56 +0100, Georg Brandl a écrit :
> For 3.3, I'd like to revive the tradition of listing planned large-scale
> changes in the PEP. Please let me know if you plan any such changes,
> at any time. (If they aren't codified in PEP form, we should think about
> whether the
Hi,
I plan to replace all %.100s (or any other size, %\.[0-9]+s regex) by %s
in the whole source code, in all calls to PyErr_Format(). And I would
like your opinion.
When Guido added the function PyErr_Format(), 13 years ago, the function
was implemented using a buffer of 500 bytes (allocated on
2401 - 2500 of 3215 matches
Mail list logo
