Re: [Python-Dev] Thoughts fresh after EuroPython
On 7/26/2010 7:36 AM, Guido van Rossum wrote: According to CSP advicates, this approach will break down when you need more than 8-16 cores since cache coherence breaks down at 16 cores. Then you would have to figure out a message-passing approach (but the messages would have to be very fast). Catching up on Python-Dev after 3 months of travel (lucky me!), so apologies for a "blast from the past" as I'm 6 weeks late in replying here. Think of the hardware implementation of cache coherence as a MIL - memory interleave lock, or a micro interpreter lock (the hardware is interpreting what the compiled software is doing). That is not so different than Python's GIL, just at a lower level. I didn't read the CSP advocacy papers, but experience in early parallel system at CMU, Tandem Computers, and Teradata strongly imply that multiprocessing of some sort will always be able to scale larger than memory coherent cores -- if the application can be made parallel at all. It is interesting to note that all the parallel systems mentioned above implemented fast message passing hardware of various sorts (affected by available technologies of their times). It is interesting to note the similarities between some of the extreme multi-way cache coherence approaches and the various message passing hardware, also... some of the papers that talk about exceeding 16 cores were going down a message passing road to achieve it. Maybe something new has been discovered in the last 8 years since I've not been following the research... the only thing I've read about that in the last 8 years is the loss of Jim Gray at sea... but the IEEE paper you posted later seems to confirm my suspicions that there has not yet been a breakthrough. The point of the scalability remark, though, is that while lots of problems can be solved on a multi-core system, problems also grow bigger, and there will likely always be problems that cannot be solved on a multi-core (single cache coherent memory) system. Those problems will require message passing solutions. Experience with the systems above has shown that switching from a multi-core (semaphore based) design to a message passing design is usually a rewrite. Perhaps the existence of the GIL, forcing a message passing solution to be created early, is a blessing in disguise for the design of large scale applications. I've been hearing about problems for which the data is too large to share, and the calculation is too complex to parallelize for years, but once the available hardware is exhausted as the problem grows, the only path to larger scale is message passing parallelism... forcing a redesign of applications that outgrew the available hardware. That said, applications that do fit in available hardware generally can run a little faster with some sort of shared memory approach: message passing does have overhead. -- Glenn I have CDO..It's like OCD, but in alphabetical order..The way it should be! (a facebook group is named this, except for a misspelling.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3149 thoughts
On Sep 05, 2010, at 11:39 PM, Martin v. Löwis wrote:
>Notice, however, that the PEP also talks about creating different names
>for different compilation options of the same Python binary. This
>applies to Windows as well (as the PEP actually points out: there is
>_d.pyd and .pyd).
>
>In any case, if the PEP is specific to Unix (or even to Linux?), it
>should say so (either as a positive list, or a negative one; if
>negative, it should also say whether it applies to OSX).
Section added:
Windows
===
This PEP only addresses build issues on POSIX systems that use the
``configure`` script. While Windows or other platform support is not
explicitly disallowed under this PEP, platform expertise is needed in
order to evaluate, describe, and implement support on such platforms.
It is not currently clear that the facilities in this PEP are even
useful for Windows.
>> That section is talking about files installed by distributions,
>> which need to take special steps to get everything
>> into /usr/{lib,share}/pyshared; a standard out-of-the-tarball
>> install will not change the way it is installed.
>>
>> It may well be that Barry had his Ubuntu hat on a bit too firmly
>> when writing that PEP :)
>
>I think then that the PEP should better separate what is actually being
>specified (and apparently, that's just the name of the shared objects),
>from possible use case scenarios.
I'm not really sure what to do about this.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3149 thoughts
On Sep 06, 2010, at 03:40 PM, David Cournapeau wrote: >Reading the related paragraph in the PEP, it seems to me that the use >of package as in "these distributions install third party (i.e. >non-standard library) packages ..." is too vague. Rephrased as: [...]these distributions install third party package modules (``.pyc`` and ``.so`` files) into `/usr/share/pyshared`[...] -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3149 thoughts
On Sep 05, 2010, at 07:22 PM, Martin v. Löwis wrote: >I know the PEP is accepted, but I would still like to see some >changes/clarifications. > >1. What is the effect of this PEP on Windows? Is this a Linux-only > feature? If not, who is going to provide the changes for Windows? > (More specifically: if this is indeed meant for Windows, and > if no Windows implementation arrives before 3.2b1, I'd ask that > the changes be rolled back, and integration is deferred until there > is Windows support) I only mandated ./configure-based builds to be PEP 3149 conforming. I have no objection to expanding the PEP to include Windows builds, but I'm not sure it's necessary and it would take a Windows build expert to make and test those changes. Does PEP 3149 have any advantage for Windows installations? >2. Why does the PEP recommend installing stuff >into /usr/share/pyshared? It's just a suggestion, but as it turns out, probably an incorrect one. I'll rephrase this to make it clear that it's up to the distribution as to where exactly these files get installed. Nothing about this PEP changes the default from-source installation directory. > According to the Linux FHS, /usr/share is for Architecture- > independent data, see > >http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA > In particular, it's objective is that you can NFS-share it across, > say, both SPARC Linux and x86 Linux. I believe the PEP would break > this, as SPARC and x86 executables would override each other. > >3. When the PEP recommends that stuff gets installed into pyshared, > why does the patch then not implement this recommendation, but > continues installing files into lib-dynload? See above. It is not the intent of this PEP to change the installation directories. Distributions have all the other tools they need to get the files into the right place for their layouts. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 status
On Wed, Sep 8, 2010 at 2:48 AM, M.-A. Lemburg wrote: > "Martin v. Löwis" wrote: >> >>> This sounds like the issues such a mix can cause are mostly >>> theoretical and don't really bother much in practice, so >>> PEP 384 on Windows does have a chance :-) >> >> Actually, the CRT issues (FILE* in particular) have been >> causing real crashes for many years, for many people. > > Do you have some pointers ? I don't have a bug report, but I have had issues in my audiolab package, where the package itself is built with visual studio, but the library it is linked against is built with mingw (libsndfile, which cannot be built with visual studio). The problem happens when you want to use the mingw-built library which accepts a file descriptor that you create with mkstemp inside code built with Visual Studio. This issue is actually quite easy to reproduce. > I don't remember this being a real practical issue, at least > not for different versions of the MS CRTs. I would turn the question around: what are the cases where you manage to mix CRT and not getting any issues ? This has never worked in my own experience in the context of python extensions, cheers, David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84562 - in python/branches/py3k: Doc/library/io.rst Lib/_pyio.py Lib/test/test_memoryio.py Misc/NEWS Modules/_io/_iomodule.c Modules/_io/_iomodule.h Modules/_io/byt
On Wed, Sep 8, 2010 at 3:39 AM, Benjamin Peterson wrote: > 2010/9/7 Nick Coghlan : >> I've raised an RFE (http://bugs.python.org/issue9789) to point out >> that the need for that GC collect call in there to make the test >> portable to other implementations is rather ugly > > Why? You're testing garbage collection, so you should call garbage collection. Having that test *as well* as a specific release test (to check implicit as well as explicit release) is a different story (we do that for generators, files and assorted other things). Having forced GC invocation be the only way to do explicit release is the part I found ugly. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Behaviour of max() and min() with equal keys
On Tue, Sep 7, 2010 at 11:00 PM, Mark Dickinson wrote: > On Tue, Sep 7, 2010 at 10:51 PM, Mark Dickinson wrote: >> On Tue, Sep 7, 2010 at 10:47 PM, Jeffrey Yasskin wrote: >>> It's ignoring the order of the arguments. It also creates >>> a new Decimal object for the return value, so I can't use id() to >>> check which one of identical elements it returns. >> >> This bit surprises me. I honestly thought I'd fixed it up so that >> max(x, y) actually returned one of x and y (and min(x, y) returned the >> other). Oh well. > > Ah. I'd forgotten that the Decimal max and min methods are context > aware, so that max(x, y) is rounded to the current context, and hence > can actually be different from both x and y. So that was a bad > example from me. Sorry. Grr. s/max(x, y)/x.max(y)/g Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Behaviour of max() and min() with equal keys
On Tue, Sep 7, 2010 at 10:51 PM, Mark Dickinson wrote:
> On Tue, Sep 7, 2010 at 10:47 PM, Jeffrey Yasskin wrote:
>> It's ignoring the order of the arguments. It also creates
>> a new Decimal object for the return value, so I can't use id() to
>> check which one of identical elements it returns.
>
> This bit surprises me. I honestly thought I'd fixed it up so that
> max(x, y) actually returned one of x and y (and min(x, y) returned the
> other). Oh well.
Ah. I'd forgotten that the Decimal max and min methods are context
aware, so that max(x, y) is rounded to the current context, and hence
can actually be different from both x and y. So that was a bad
example from me. Sorry.
>>> from decimal import *
>>> getcontext().Emin = -500
>>> x, y = Decimal('-1e-100'), Decimal('-1e-1000')
>>> x.max(y)
Decimal('-0E-527')
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84536 - sandbox/trunk/release/release.py
On Sep 05, 2010, at 08:28 PM, georg.brandl wrote:
>Author: georg.brandl
>Date: Sun Sep 5 20:28:46 2010
>New Revision: 84536
>
>Log:
>Fix after changing NEWS layout.
>
>Modified:
> sandbox/trunk/release/release.py
>
>Modified: sandbox/trunk/release/release.py
>==
>--- sandbox/trunk/release/release.py (original)
>+++ sandbox/trunk/release/release.py Sun Sep 5 20:28:46 2010
>@@ -396,13 +396,13 @@
> with open('Misc/NEWS', encoding="utf-8") as fp:
> lines = fp.readlines()
> for i, line in enumerate(lines):
>-if line.startswith("(editors"):
>+if line.startswith("Python News"):
> start = i
> if line.startswith("What's"):
> end = i
> break
> with open('Misc/NEWS', 'w', encoding="utf-8") as fp:
>- fp.writelines(lines[:start+1])
>+ fp.writelines(lines[:start+2])
> fp.write(NEWS_TEMPLATE)
> fp.writelines(lines[end-1:])
> print("Please fill in the the name of the next version.")
Will this still work with the Python 2.7 NEWS file?
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Behaviour of max() and min() with equal keys
On Tue, Sep 7, 2010 at 10:40 PM, Jeffrey Yasskin wrote: > Decimal may actually have this backwards. The idea would be that > min(*lst) == sorted(lst)[0], and max(*lst) == sorted(lst)[-1]. Given a > stable sort, then, max of equivalent elements would return the last > element, and min the first. Yes, you're right; that would make more sense than the other way around. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Behaviour of max() and min() with equal keys
On Tue, Sep 7, 2010 at 10:47 PM, Jeffrey Yasskin wrote:
> Actually, Decimal isn't doing anything along these lines. At least in
> Python 2.6, I get:
>
Decimal('2').max(Decimal('2.0'))
> Decimal('2')
Decimal('2.0').max(Decimal('2'))
> Decimal('2')
Decimal('2.0').min(Decimal('2'))
> Decimal('2.0')
Decimal('2').min(Decimal('2.0'))
> Decimal('2.0')
>
> indicating that '2' is considered larger than '2.0' in the min/max
> comparison.
Right; there's a strict specification about how equal values with
different exponents (or different signs in the case of comparing
zeros) should be treated.
> It's ignoring the order of the arguments. It also creates
> a new Decimal object for the return value, so I can't use id() to
> check which one of identical elements it returns.
This bit surprises me. I honestly thought I'd fixed it up so that
max(x, y) actually returned one of x and y (and min(x, y) returned the
other). Oh well.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Behaviour of max() and min() with equal keys
On Tue, Sep 7, 2010 at 2:40 PM, Jeffrey Yasskin wrote:
> On Tue, Sep 7, 2010 at 1:44 PM, Mark Dickinson wrote:
>> On Tue, Sep 7, 2010 at 8:34 PM, Matthew Woodcraft
>> wrote:
>>> In CPython, the builtin max() and min() have the property that if there
>>> are items with equal keys, the first item is returned. From a quick look
>>> at their source, I think this is true for Jython and IronPython too.
>>
>> It's actually not clear to me that this behaviour is ideal; it might
>> make more sense to have max() return the first item among equal
>> largest elements, and min() return the last item. That way, the
>> special case of two operands has the nice property that (max(x, y),
>> min(x, y)) is always either (x, y) or (y, x), rather than being
>> possibly (x, x) or (y, y). (That is, id(max(x, y)) and id(min(x, y))
>> are id(x) and id(y) in one order or the other.)
>>
>> The max and min methods for the Decimal module take care to work this
>> way, for example:
>>
> x, y = Decimal(2), Decimal('2.0')
> x.max(y), x.min(y)
>> (Decimal('2'), Decimal('2.0'))
>>
>> But:
>>
> max(x, y), min(x, y)
>> (Decimal('2'), Decimal('2'))
>>
>
> Decimal may actually have this backwards. The idea would be that
> min(*lst) == sorted(lst)[0], and max(*lst) == sorted(lst)[-1]. Given a
> stable sort, then, max of equivalent elements would return the last
> element, and min the first. According to Alex Stepanov, this helps
> some with composing these small order statistics into larger
> stably-ordered functions.
>
> I do think Decimal.max's answer is better than the builtin's answer,
> and that the incremental benefit from returning the last instead of
> first is pretty small.
Actually, Decimal isn't doing anything along these lines. At least in
Python 2.6, I get:
>>> Decimal('2').max(Decimal('2.0'))
Decimal('2')
>>> Decimal('2.0').max(Decimal('2'))
Decimal('2')
>>> Decimal('2.0').min(Decimal('2'))
Decimal('2.0')
>>> Decimal('2').min(Decimal('2.0'))
Decimal('2.0')
indicating that '2' is considered larger than '2.0' in the min/max
comparison. It's ignoring the order of the arguments. It also creates
a new Decimal object for the return value, so I can't use id() to
check which one of identical elements it returns.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Behaviour of max() and min() with equal keys
On Tue, Sep 7, 2010 at 1:44 PM, Mark Dickinson wrote:
> On Tue, Sep 7, 2010 at 8:34 PM, Matthew Woodcraft
> wrote:
>> In CPython, the builtin max() and min() have the property that if there
>> are items with equal keys, the first item is returned. From a quick look
>> at their source, I think this is true for Jython and IronPython too.
>
> It's actually not clear to me that this behaviour is ideal; it might
> make more sense to have max() return the first item among equal
> largest elements, and min() return the last item. That way, the
> special case of two operands has the nice property that (max(x, y),
> min(x, y)) is always either (x, y) or (y, x), rather than being
> possibly (x, x) or (y, y). (That is, id(max(x, y)) and id(min(x, y))
> are id(x) and id(y) in one order or the other.)
>
> The max and min methods for the Decimal module take care to work this
> way, for example:
>
x, y = Decimal(2), Decimal('2.0')
x.max(y), x.min(y)
> (Decimal('2'), Decimal('2.0'))
>
> But:
>
max(x, y), min(x, y)
> (Decimal('2'), Decimal('2'))
>
Decimal may actually have this backwards. The idea would be that
min(*lst) == sorted(lst)[0], and max(*lst) == sorted(lst)[-1]. Given a
stable sort, then, max of equivalent elements would return the last
element, and min the first. According to Alex Stepanov, this helps
some with composing these small order statistics into larger
stably-ordered functions.
I do think Decimal.max's answer is better than the builtin's answer,
and that the incremental benefit from returning the last instead of
first is pretty small.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Behaviour of max() and min() with equal keys
Mark Dickinson wrote: > Matthew Woodcraft wrote: >> In CPython, the builtin max() and min() have the property that if there >> are items with equal keys, the first item is returned. From a quick look >> at their source, I think this is true for Jython and IronPython too. > It's actually not clear to me that this behaviour is ideal; it might > make more sense to have max() return the first item among equal > largest elements, and min() return the last item. I don't care a great deal what the behaviour is; I would like it to be consistent across Python versions, and I think the pragmatic way to achieve that is to document the current behaviour. > Can you give examples of code that relies on max and min returning the > first among equals? An existing regression test whose output depends on which choice is made. (I was writing some code today which had to duplicate the behaviour of a non-Python program which uses first-among-equals, which is what brought this question up. In that case I wouldn't think it unreasonable to have to hand-code the loop rather than using max(), but if in practice Python is always going to be first-among-equals, it seems to me we might as well be 'allowed' to take advantage of it.) -M- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Behaviour of max() and min() with equal keys
FWIW: I think Mark is right. I never quite understood why that was, but never cared enough to complain. lvh ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Behaviour of max() and min() with equal keys
On Tue, Sep 7, 2010 at 8:34 PM, Matthew Woodcraft
wrote:
> In CPython, the builtin max() and min() have the property that if there
> are items with equal keys, the first item is returned. From a quick look
> at their source, I think this is true for Jython and IronPython too.
It's actually not clear to me that this behaviour is ideal; it might
make more sense to have max() return the first item among equal
largest elements, and min() return the last item. That way, the
special case of two operands has the nice property that (max(x, y),
min(x, y)) is always either (x, y) or (y, x), rather than being
possibly (x, x) or (y, y). (That is, id(max(x, y)) and id(min(x, y))
are id(x) and id(y) in one order or the other.)
The max and min methods for the Decimal module take care to work this
way, for example:
>>> x, y = Decimal(2), Decimal('2.0')
>>> x.max(y), x.min(y)
(Decimal('2'), Decimal('2.0'))
But:
>>> max(x, y), min(x, y)
(Decimal('2'), Decimal('2'))
Can you give examples of code that relies on max and min returning the
first among equals?
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] versioned .so files for Python 3.2
Amaury Forgeot d'Arc wrote: > Hi, > > 2010/9/7 M.-A. Lemburg : >>> Ok. I'm fine with excluding Py_UNICODE from the stable ABI. However, >>> I think in the long run, I guess more support for wchar_t will then >>> be needed in the API, e.g. more convenient argument parsing. >> >> Sure, we could add that. > > Just to be clear: does this mean that PyUnicode_FromUnicode() and > PyUnicode_AsUnicode() won't belong to the stable ABI? As I understood Martin's comment Py_UNICODE would not be part of the ABI in the sense that you can access the Py_UNICODE data from within the extension module. It should still be fine, passing around opaque Py_UNICODE buffers. > PyUnicode_AsWideChar() is not as fast, because it needs to copy the data. True. Also see this patch which tries to address the issue: http://bugs.python.org/issue8654 With the terminology used there, the stable ABI would implicitly have Py_UNICODE_AGNOSTIC set - and then prevent exposing the structure of Py_UNICODE* buffers while still allowing to pass them around. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 07 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2010-08-19: Released mxODBC 3.1.0 http://python.egenix.com/ 2010-09-15: DZUG Tagung, Dresden, Germany 7 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Behaviour of max() and min() with equal keys
In CPython, the builtin max() and min() have the property that if there are items with equal keys, the first item is returned. From a quick look at their source, I think this is true for Jython and IronPython too. However, this isn't currently a documented guarantee. Could it be made so? (As with the decision to declare sort() stable, it seems likely that by now there's code out there relying on it anyway.) -M- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] versioned .so files for Python 3.2
Hi, 2010/9/7 M.-A. Lemburg : >> Ok. I'm fine with excluding Py_UNICODE from the stable ABI. However, >> I think in the long run, I guess more support for wchar_t will then >> be needed in the API, e.g. more convenient argument parsing. > > Sure, we could add that. Just to be clear: does this mean that PyUnicode_FromUnicode() and PyUnicode_AsUnicode() won't belong to the stable ABI? PyUnicode_AsWideChar() is not as fast, because it needs to copy the data. -- Amaury Forgeot d'Arc ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 status
"Martin v. Löwis" wrote: > >> This sounds like the issues such a mix can cause are mostly >> theoretical and don't really bother much in practice, so >> PEP 384 on Windows does have a chance :-) > > Actually, the CRT issues (FILE* in particular) have been > causing real crashes for many years, for many people. Do you have some pointers ? I don't remember this being a real practical issue, at least not for different versions of the MS CRTs. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 07 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2010-08-19: Released mxODBC 3.1.0 http://python.egenix.com/ 2010-09-15: DZUG Tagung, Dresden, Germany 7 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] versioned .so files for Python 3.2
"Martin v. Löwis" wrote: >> -1 on always using wchar_t as well. Python's default is UCS2 and the >> stable ABI should not change that. > > It's not really Python's default. It is what configure.in does by > default. Python's default, on Linux, is UCS-4. No, the default is UCS2 on all platforms and in configure.in. configure.in only uses UCS4 if it finds a TCL installation that happens to use UCS4 - for some reason I don't know :-) However, most Linux distros and more recently also some BSDs have switched over to using UCS4 for their distribution versions of Python. >> I also think that this information is not relevant for the stable >> ABI: Extensions that want to stick to the stable ABI should really >> not have to know whether Py_UNICODE maps to wchar_t or not. If they >> want to interface to a local whcar_t type they can use the conversion >> APIs we have for that in the Unicode API: PyUnicode_FromWideChar() >> and PyUnicode_AsWideChar(). > > Ok. I'm fine with excluding Py_UNICODE from the stable ABI. However, > I think in the long run, I guess more support for wchar_t will then > be needed in the API, e.g. more convenient argument parsing. Sure, we could add that. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 07 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2010-08-19: Released mxODBC 3.1.0 http://python.egenix.com/ 2010-09-15: DZUG Tagung, Dresden, Germany 7 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84562 - in python/branches/py3k: Doc/library/io.rst Lib/_pyio.py Lib/test/test_memoryio.py Misc/NEWS Modules/_io/_iomodule.c Modules/_io/_iomodule.h Modules/_io/byt
2010/9/7 Nick Coghlan : > I've raised an RFE (http://bugs.python.org/issue9789) to point out > that the need for that GC collect call in there to make the test > portable to other implementations is rather ugly Why? You're testing garbage collection, so you should call garbage collection. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Push notification
On Tue, Sep 7, 2010 at 10:38 AM, Antoine Pitrou wrote: > Could push notification be added for the benchmarks repo? > I think the python-checkins list would be an appropriate recipient for > the e-mails (the repo has a low activity). +1 -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Push notification
On Tue, Sep 7, 2010 at 16:38, Antoine Pitrou wrote: > Could push notification be added for the benchmarks repo? > I think the python-checkins list would be an appropriate recipient for > the e-mails (the repo has a low activity). Fine with me, if the list agrees. Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Volunteer help with porting
> Other interesting bugs: > http://bugs.python.org/issue7962 > http://bugs.python.org/issue8077 Thanks, I will look into these bugs and see if I can fix them. > > Maybe you can post a call on python-list and form a small group of py3k > porters. > I have already mailed the python-list ML and am expecting a reply. pk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Volunteer help with porting
On Tue, Sep 07, 2010 at 02:58:41PM -, exar...@twistedmatrix.com wrote: > On 02:34 pm, p...@phd.pp.ru wrote: >> On Tue, Sep 07, 2010 at 02:02:59PM -, exar...@twistedmatrix.com >> wrote: >>> On 01:33 pm, p...@phd.pp.ru wrote: As there is already Python 3.2 alpha, the core of Python has already been ported >>> >>> How about the email package? >> >> What about email? It is a core library, right? It has been ported >> AFAIK. >> Or have I missed something? > > Are you just assuming that because there have been 3.x releases, > everything in the standard library works properly in 3.x? Or do you > know something about the email package specifically? Yes, I assumed that because the core team planned a beta release of 3.2 for October. "3.2" sounds more stable and complete than "3.0". > Last I checked, there were a number of outstanding issues with email in > 3.x. And as Michael Foord pointed out, there are other standard library > modules in the same state. I see. Thank you for the clarification. I am sorry for being so haste. Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Volunteer help with porting
On 9/7/2010 10:15 AM, Michael Foord wrote: Right, and there are other standard library modules (cgi, ftplib, nntplib, etc) that either need fixing or auditing as to how they handle bytes / strings. If you wanted to help with the documentation of the stdlib, one thing that needs to be done is run doctest over the examples. See http://bugs.python.org/issue9730 for an example where the examples were not properly ported (two 'b' prefixes need to be added). Of course, there are other errors to be found. More contributions from additional contributors are welcome! -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Volunteer help with porting
On Tue, 07 Sep 2010 18:34:49 +0400, Oleg Broytman wrote: > On Tue, Sep 07, 2010 at 02:02:59PM -, exar...@twistedmatrix.com wrote: > > On 01:33 pm, p...@phd.pp.ru wrote: > >> As there is already Python 3.2 alpha, the core of Python has already > >> been ported > > > > How about the email package? > >What about email? It is a core library, right? It has been ported AFAIK. > Or have I missed something? Some bug reports, perhaps? Email has been "ported" in the sense that all the existing tests pass under py3k. It is not, however, fully functional: it cannot handle input that contains binary data with the high bit set. (To put it another way, the python3 email package currently handles only 7bit clean data.) This has various unfortunate consequences for other standard library packages (cgi, nntp, etc) that depend directly or indirectly on the email package. To fix this the email package API and a chunk of the internals needs to be redesigned so that it can handle bytes while still providing a string-based interface to the textual data. This is no small task, since email in python2 has been getting away with all kinds of dirty tricks because of the lack of a clean bytes/string separation in python2. See http://launchpad.net/python-email6 for current status of the project. Prashant Kumar, if you would like to help with the email6 project, please sign up to the email-sig mailing list and introduce yourself there. All help is welcome! It is not a "porting" project strictly speaking, but it certainly is interesting :) -- R. David Murray www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Volunteer help with porting
On Tue, 7 Sep 2010 20:12:26 +0530 Prashant Kumar wrote: > > > > Right, and there are other standard library modules (cgi, ftplib, nntplib, > > etc) that either need fixing or auditing as to how they handle bytes / > > strings. > > > > Sure I will look into this. Could you please point me towards the > repository(I'd love it if I could use mercurial for the development process > rather than svn)?. http://code.python.org/hg/branches/py3k/ Also don't forget to check for relevant issues on http://bugs.python.org For example, NNTP-related issues (either bugs or feature wishes): http://bugs.python.org/issue1926 http://bugs.python.org/issue7644 Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Volunteer help with porting
> Sure I will look into this. Could you please point me towards the > repository(I'd love it if I could use mercurial for the development process > rather than svn)?. Core developers still use Subversion (we’re in the process of switching), but you can clone the mirror at http://code.python.org/hg/branches/py3k/ and use named branches for your work. You can look for bugs needing patches on bugs.python.org or open reports and then post patches. The email package is a high-priority task, but it’s not trivial. R. David Murray and Shashwat Anand will maybe comment about the status of the port. Other interesting bugs: http://bugs.python.org/issue7962 http://bugs.python.org/issue8077 Maybe you can post a call on python-list and form a small group of py3k porters. Happy hacking ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Volunteer help with porting
On 02:34 pm, p...@phd.pp.ru wrote: On Tue, Sep 07, 2010 at 02:02:59PM -, exar...@twistedmatrix.com wrote: On 01:33 pm, p...@phd.pp.ru wrote: As there is already Python 3.2 alpha, the core of Python has already been ported How about the email package? What about email? It is a core library, right? It has been ported AFAIK. Or have I missed something? Are you just assuming that because there have been 3.x releases, everything in the standard library works properly in 3.x? Or do you know something about the email package specifically? Last I checked, there were a number of outstanding issues with email in 3.x. And as Michael Foord pointed out, there are other standard library modules in the same state. Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Volunteer help with porting
On Tue, Sep 7, 2010 at 7:45 PM, Michael Foord wrote: > On 07/09/2010 15:02, exar...@twistedmatrix.com wrote: > >> On 01:33 pm, p...@phd.pp.ru wrote: >> >>> Hello. Thank you for the offer! >>> >>> On Tue, Sep 07, 2010 at 06:36:10PM +0530, Prashant Kumar wrote: >>> My name is Prashant Kumar and I wish to contribute to the Python development process by helping convert certain existing python over to python3k. Is there anyway I could obtain a list of libraries which need to be ported over to python3k, sorted by importance(by importance i mean packages which serve as a dependency for larger number of packages being more important). >>> >>> As there is already Python 3.2 alpha, the core of Python has already >>> been ported - and this mailing list is for discussion of development of >>> the >>> very Python, not about working on 3rd-party libraries. >>> >> >> How about the email package? >> > > Right, and there are other standard library modules (cgi, ftplib, nntplib, > etc) that either need fixing or auditing as to how they handle bytes / > strings. > Sure I will look into this. Could you please point me towards the repository(I'd love it if I could use mercurial for the development process rather than svn)?. pk > > Michael > > >> Jean-Paul >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk >> > > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > READ CAREFULLY. By accepting and reading this email you agree, on behalf of > your employer, to release me from all obligations and waivers arising from > any and all NON-NEGOTIATED agreements, licenses, terms-of-service, > shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, > non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have > entered into with your employer, its partners, licensors, agents and > assigns, in perpetuity, without prejudice to my ongoing rights and > privileges. You further represent that you have the authority to release me > from any BOGUS AGREEMENTS on behalf of your employer. > > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/contactprashantat%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Push notification
On Tue, 7 Sep 2010 10:29:48 +0200 Dirkjan Ochtman wrote: > > and your URI is > > > > ssh://h...@hg.python.org/repos/benchmarks > > > > (That may change depending on the final setup, of course.) > > Yes, I think I'd prefer to just get rid of the /repos/ for the URLs > (which makes http and ssh more similar, for one thing). Could push notification be added for the benchmarks repo? I think the python-checkins list would be an appropriate recipient for the e-mails (the repo has a low activity). Thanks Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Volunteer help with porting
On Tue, Sep 07, 2010 at 02:02:59PM -, exar...@twistedmatrix.com wrote: > On 01:33 pm, p...@phd.pp.ru wrote: >> As there is already Python 3.2 alpha, the core of Python has already >> been ported > > How about the email package? What about email? It is a core library, right? It has been ported AFAIK. Or have I missed something? Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Volunteer help with porting
Hello, > My name is Prashant Kumar and I wish to contribute to the Python development > process by helping convert certain existing python > over to python3k. > > Is there anyway I could obtain a list of libraries which need to be ported > over to python3k, sorted by importance(by importance i mean > packages which serve as a dependency for larger number of packages being > more important). I think you should ask on comp.lang.python for people's suggestions. Also, be aware that some libraries might already be in the process of being ported. If you consider working on a library, it is probably good practice to first ask its authors about the status of py3k porting. I hope you'll find a place where you can contribute. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Volunteer help with porting
On 07/09/2010 15:02, exar...@twistedmatrix.com wrote: On 01:33 pm, p...@phd.pp.ru wrote: Hello. Thank you for the offer! On Tue, Sep 07, 2010 at 06:36:10PM +0530, Prashant Kumar wrote: My name is Prashant Kumar and I wish to contribute to the Python development process by helping convert certain existing python over to python3k. Is there anyway I could obtain a list of libraries which need to be ported over to python3k, sorted by importance(by importance i mean packages which serve as a dependency for larger number of packages being more important). As there is already Python 3.2 alpha, the core of Python has already been ported - and this mailing list is for discussion of development of the very Python, not about working on 3rd-party libraries. How about the email package? Right, and there are other standard library modules (cgi, ftplib, nntplib, etc) that either need fixing or auditing as to how they handle bytes / strings. Michael Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Volunteer help with porting
On Tue, Sep 7, 2010 at 11:33 PM, Oleg Broytman wrote: > -- GUI frameworks, especially wxPython. That would be very cool, but the practicality of it will depend on how current the version of SWIG used in wxPython's build process happens to be. A version of wxPython built around SWIG's -py3 option could be quite interesting. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84576 - in python/branches/py3k: Doc/library/random.rst Lib/random.py Lib/test/test_random.py Misc/NEWS
On Tue, 7 Sep 2010 06:44:52 +0200 (CEST)
raymond.hettinger wrote:
> Author: raymond.hettinger
> Date: Tue Sep 7 06:44:52 2010
> New Revision: 84576
>
> Log:
> Issues #7889, #9025 and #9379: Improvements to the random module.
This broke test_generators here:
[1/1] test_generators
**
File "/home/antoine/py3k/py3k/Lib/test/test_generators.py", line ?, in
test.test_generators.__test__.email Failed example:
while 1:
for s in sets:
print(" %s->%s" % (s, s.find()), end='')
print()
if len(roots) > 1:
s1 = gen.choice(roots)
roots.remove(s1)
s2 = gen.choice(roots)
s1.union(s2)
print("merged", s1, "into", s2)
else:
break
Expected:
A->A B->B C->C D->D E->E F->F G->G H->H I->I J->J K->K L->L M->M
merged I into A
A->A B->B C->C D->D E->E F->F G->G H->H I->A J->J K->K L->L M->M
merged D into C
A->A B->B C->C D->C E->E F->F G->G H->H I->A J->J K->K L->L M->M
merged K into H
A->A B->B C->C D->C E->E F->F G->G H->H I->A J->J K->H L->L M->M
merged L into A
A->A B->B C->C D->C E->E F->F G->G H->H I->A J->J K->H L->A M->M
merged E into A
A->A B->B C->C D->C E->A F->F G->G H->H I->A J->J K->H L->A M->M
merged B into G
A->A B->G C->C D->C E->A F->F G->G H->H I->A J->J K->H L->A M->M
merged A into F
A->F B->G C->C D->C E->F F->F G->G H->H I->F J->J K->H L->F M->M
merged H into G
A->F B->G C->C D->C E->F F->F G->G H->G I->F J->J K->G L->F M->M
merged F into J
A->J B->G C->C D->C E->J F->J G->G H->G I->J J->J K->G L->J M->M
merged M into C
A->J B->G C->C D->C E->J F->J G->G H->G I->J J->J K->G L->J M->C
merged J into G
A->G B->G C->C D->C E->G F->G G->G H->G I->G J->G K->G L->G M->C
merged C into G
A->G B->G C->G D->G E->G F->G G->G H->G I->G J->G K->G L->G M->G
Got:
A->A B->B C->C D->D E->E F->F G->G H->H I->I J->J K->K L->L M->M
merged K into B
A->A B->B C->C D->D E->E F->F G->G H->H I->I J->J K->B L->L M->M
merged A into F
A->F B->B C->C D->D E->E F->F G->G H->H I->I J->J K->B L->L M->M
merged E into F
A->F B->B C->C D->D E->F F->F G->G H->H I->I J->J K->B L->L M->M
merged D into C
A->F B->B C->C D->C E->F F->F G->G H->H I->I J->J K->B L->L M->M
merged M into C
A->F B->B C->C D->C E->F F->F G->G H->H I->I J->J K->B L->L M->C
merged J into B
A->F B->B C->C D->C E->F F->F G->G H->H I->I J->B K->B L->L M->C
merged B into C
A->F B->C C->C D->C E->F F->F G->G H->H I->I J->C K->C L->L M->C
merged F into G
A->G B->C C->C D->C E->G F->G G->G H->H I->I J->C K->C L->L M->C
merged L into C
A->G B->C C->C D->C E->G F->G G->G H->H I->I J->C K->C L->C M->C
merged G into I
A->I B->C C->C D->C E->I F->I G->I H->H I->I J->C K->C L->C M->C
merged I into H
A->H B->C C->C D->C E->H F->H G->H H->H I->H J->C K->C L->C M->C
merged C into H
A->H B->H C->H D->H E->H F->H G->H H->H I->H J->H K->H L->H M->H
**
1 items had failures:
1 of 31 in test.test_generators.__test__.email
***Test Failed*** 1 failures.
test test_generators failed -- 1 of 286 doctests failed
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Volunteer help with porting
On 01:33 pm, p...@phd.pp.ru wrote: Hello. Thank you for the offer! On Tue, Sep 07, 2010 at 06:36:10PM +0530, Prashant Kumar wrote: My name is Prashant Kumar and I wish to contribute to the Python development process by helping convert certain existing python over to python3k. Is there anyway I could obtain a list of libraries which need to be ported over to python3k, sorted by importance(by importance i mean packages which serve as a dependency for larger number of packages being more important). As there is already Python 3.2 alpha, the core of Python has already been ported - and this mailing list is for discussion of development of the very Python, not about working on 3rd-party libraries. How about the email package? Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84562 - in python/branches/py3k: Doc/library/io.rst Lib/_pyio.py Lib/test/test_memoryio.py Misc/NEWS Modules/_io/_iomodule.c Modules/_io/_iomodule.h Modules/_io/bytesio.c
On Tue, Sep 7, 2010 at 11:09 PM, Antoine Pitrou wrote: > On Tue, 7 Sep 2010 23:01:17 +1000 > Nick Coghlan wrote: >> > + # After the buffer gets released, we can resize the BytesIO again >> > + del buf >> > + support.gc_collect() >> > + memio.truncate() >> >> I've raised an RFE (http://bugs.python.org/issue9789) to point out >> that the need for that GC collect call in there to make the test >> portable to other implementations is rather ugly and supporting an >> explicit "buf.release()" call may be a nicer option. > > There was already an issue open for the context management option: > http://bugs.python.org/issue9757 Yeah, I didn't even think to check if you'd already put that up there. I've now closed 9789 as a duplicate of that issue. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] random guarantees
On Tue, 7 Sep 2010 02:38:15 +0200 (CEST) raymond.hettinger wrote: > Author: raymond.hettinger > Date: Tue Sep 7 02:38:15 2010 > New Revision: 84574 > > Log: > Document which part of the random module module are guaranteed. test_random fails here: == FAIL: test_guaranteed_stable (test.test_random.MersenneTwister_TestBasicOps) -- Traceback (most recent call last): File "/home/antoine/py3k/py3k/Lib/test/test_random.py", line 235, in test_guaranteed_stable '0x1.85ff833f71576p-1', '0x1.87efb37462927p-1']) AssertionError: Lists differ: ['0x1.7fafd5169cc8fp-1', '0x1 != ['0x1.9ee265c177cdep-2', '0x1 First differing element 0: 0x1.7fafd5169cc8fp-1 0x1.9ee265c177cdep-2 - ['0x1.7fafd5169cc8fp-1', - '0x1.df66035cce42ap-2', - '0x1.87773588f902cp-3', - '0x1.0b32eb7b2fd14p-3'] + ['0x1.9ee265c177cdep-2', + '0x1.bad51092e3c25p-1', + '0x1.85ff833f71576p-1', + '0x1.87efb37462927p-1'] It looks like the guarantees might be too ambitious. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Volunteer help with porting
Hello. Thank you for the offer! On Tue, Sep 07, 2010 at 06:36:10PM +0530, Prashant Kumar wrote: > My name is Prashant Kumar and I wish to contribute to the Python development > process by helping convert certain existing python > over to python3k. > > Is there anyway I could obtain a list of libraries which need to be ported > over to python3k, sorted by importance(by importance i mean > packages which serve as a dependency for larger number of packages being > more important). As there is already Python 3.2 alpha, the core of Python has already been ported - and this mailing list is for discussion of development of the very Python, not about working on 3rd-party libraries. I don't know if there are "near core" unported libraries that the core team would want to be ported. Hence the question belongs rather to python generic news groups/mailing lists/fora. See http://www.python.org/community/ . As for my personal preferences - I would like to see these ported: -- database drivers, especially MySQL-python and psycopg; -- GUI frameworks, especially wxPython. Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84559 - python/branches/py3k/Lib/subprocess.py
On Tue, Sep 7, 2010 at 08:19, Nick Coghlan wrote:
> On Tue, Sep 7, 2010 at 11:05 PM, Brian Curtin
> wrote:
> > Sure, seems reasonable to me.
> > Does """raise ValueError("Unsupported signal: {}".format(sig))""" look
> fine,
> > or is there a more preferred format when displaying bad values in
> exception
> > messages?
>
> No, that's about what I was thinking as well. When all we have is an
> error code (or similar number), it's difficult to make the associated
> error message particularly pretty.
>
> Cheers,
> Nick.
Made the adjustment in r84582 (py3k) and r84583 (release27-maint). Thanks
for the suggestion.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84564 - in python/branches/py3k/Lib: ntpath.py test/test_ntpath.py
On Tue, Sep 7, 2010 at 08:12, Nick Coghlan wrote: > On Tue, Sep 7, 2010 at 5:46 AM, brian.curtin > wrote: > > Modified: python/branches/py3k/Lib/ntpath.py > > > == > > --- python/branches/py3k/Lib/ntpath.py (original) > > +++ python/branches/py3k/Lib/ntpath.py Mon Sep 6 21:46:17 2010 > > @@ -10,7 +10,6 @@ > > import stat > > import genericpath > > from genericpath import * > > -from nt import _getfileinformation > > > > __all__ = ["normcase","isabs","join","splitdrive","split","splitext", > >"basename","dirname","commonprefix","getsize","getmtime", > > @@ -656,4 +655,10 @@ > > > > def sameopenfile(f1, f2): > > """Test whether two file objects reference the same file""" > > -return _getfileinformation(f1) == _getfileinformation(f2) > > +try: > > +from nt import _getfileinformation > > +return _getfileinformation(f1) == _getfileinformation(f2) > > +except ImportError: > > +# On other operating systems, return True if the file > descriptors > > +# are the same. > > +return f1 == f2 > > Given the potential deadlock problems with imports inside functions, > I'd prefer to see this written as either: > > try: > from nt import _getfileinformation > def sameopenfile(f1, f2): >return _getfileinformation(f1) == _getfileinformation(f2) > except ImportError: > # On other operating systems, return True if the file descriptors > # are the same. > def sameopenfile(f1, f2): >return f1 == f2 > sameopenfile.__doc__ = "Test whether two file objects reference the same > file" > > or as: > > try: > from nt import _getfileinformation > except ImportError: > # On other operating systems, file comparison is by file descriptor anyway > # so a separate file information object is unnecessary > def _getfileinformation(f): return f > > def sameopenfile(f1, f2): > """Test whether two file objects reference the same file""" > return _getfileinformation(f1) == _getfileinformation(f2) > > The latter is cleaner code, while the former is likely an unnecessary > micro-optimisation. > > Cheers, > Nick. Similar idea(s) would also apply to the function right above that, samefile. I'll create a new issue for cleaning this up. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84559 - python/branches/py3k/Lib/subprocess.py
On Tue, Sep 7, 2010 at 11:05 PM, Brian Curtin wrote:
> Sure, seems reasonable to me.
> Does """raise ValueError("Unsupported signal: {}".format(sig))""" look fine,
> or is there a more preferred format when displaying bad values in exception
> messages?
No, that's about what I was thinking as well. When all we have is an
error code (or similar number), it's difficult to make the associated
error message particularly pretty.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84564 - in python/branches/py3k/Lib: ntpath.py test/test_ntpath.py
On Tue, Sep 7, 2010 at 5:46 AM, brian.curtin wrote: > Modified: python/branches/py3k/Lib/ntpath.py > == > --- python/branches/py3k/Lib/ntpath.py (original) > +++ python/branches/py3k/Lib/ntpath.py Mon Sep 6 21:46:17 2010 > @@ -10,7 +10,6 @@ > import stat > import genericpath > from genericpath import * > -from nt import _getfileinformation > > __all__ = ["normcase","isabs","join","splitdrive","split","splitext", > "basename","dirname","commonprefix","getsize","getmtime", > @@ -656,4 +655,10 @@ > > def sameopenfile(f1, f2): > """Test whether two file objects reference the same file""" > - return _getfileinformation(f1) == _getfileinformation(f2) > + try: > + from nt import _getfileinformation > + return _getfileinformation(f1) == _getfileinformation(f2) > + except ImportError: > + # On other operating systems, return True if the file descriptors > + # are the same. > + return f1 == f2 Given the potential deadlock problems with imports inside functions, I'd prefer to see this written as either: try: from nt import _getfileinformation def sameopenfile(f1, f2): return _getfileinformation(f1) == _getfileinformation(f2) except ImportError: # On other operating systems, return True if the file descriptors # are the same. def sameopenfile(f1, f2): return f1 == f2 sameopenfile.__doc__ = "Test whether two file objects reference the same file" or as: try: from nt import _getfileinformation except ImportError: # On other operating systems, file comparison is by file descriptor anyway # so a separate file information object is unnecessary def _getfileinformation(f): return f def sameopenfile(f1, f2): """Test whether two file objects reference the same file""" return _getfileinformation(f1) == _getfileinformation(f2) The latter is cleaner code, while the former is likely an unnecessary micro-optimisation. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84562 - in python/branches/py3k: Doc/library/io.rst Lib/_pyio.py Lib/test/test_memoryio.py Misc/NEWS Modules/_io/_iomodule.c Modules/_io/_iomodule.h Modules/_io/bytesio.c
On Tue, 7 Sep 2010 23:01:17 +1000 Nick Coghlan wrote: > > + # After the buffer gets released, we can resize the BytesIO again > > + del buf > > + support.gc_collect() > > + memio.truncate() > > I've raised an RFE (http://bugs.python.org/issue9789) to point out > that the need for that GC collect call in there to make the test > portable to other implementations is rather ugly and supporting an > explicit "buf.release()" call may be a nicer option. There was already an issue open for the context management option: http://bugs.python.org/issue9757 Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Volunteer help with porting
Hi everyone, My name is Prashant Kumar and I wish to contribute to the Python development process by helping convert certain existing python over to python3k. Is there anyway I could obtain a list of libraries which need to be ported over to python3k, sorted by importance(by importance i mean packages which serve as a dependency for larger number of packages being more important). Thanks, Prashant Kumar ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84559 - python/branches/py3k/Lib/subprocess.py
On Tue, Sep 7, 2010 at 07:34, Nick Coghlan wrote:
> On Tue, Sep 7, 2010 at 2:29 AM, brian.curtin
> wrote:
> > Author: brian.curtin
> > Date: Mon Sep 6 18:29:29 2010
> > New Revision: 84559
> >
> > Log:
> > Fix #8956. ValueError message was only mentioning one signal.
> >
> > Rather than list out the three signals (or more over time), the message
> was
> > made less specific but still descriptive.
> >
> >
> >
> > Modified:
> > python/branches/py3k/Lib/subprocess.py
> >
> > Modified: python/branches/py3k/Lib/subprocess.py
> >
> ==
> > --- python/branches/py3k/Lib/subprocess.py (original)
> > +++ python/branches/py3k/Lib/subprocess.py Mon Sep 6 18:29:29 2010
> > @@ -983,7 +983,7 @@
> > elif sig == signal.CTRL_BREAK_EVENT:
> > os.kill(self.pid, signal.CTRL_BREAK_EVENT)
> > else:
> > -raise ValueError("Only SIGTERM is supported on Windows")
> > +raise ValueError("Unsupported signal")
>
> Would it be worth including the signal number here, to at least give
> some hint as to exactly which signal was received?
>
> Cheers,
> Nick.
Sure, seems reasonable to me.
Does """raise ValueError("Unsupported signal: {}".format(sig))""" look fine,
or is there a more preferred format when displaying bad values in exception
messages?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84562 - in python/branches/py3k: Doc/library/io.rst Lib/_pyio.py Lib/test/test_memoryio.py Misc/NEWS Modules/_io/_iomodule.c Modules/_io/_iomodule.h Modules/_io/byt
On Tue, Sep 7, 2010 at 4:48 AM, antoine.pitrou wrote: > Modified: python/branches/py3k/Lib/test/test_memoryio.py > == > --- python/branches/py3k/Lib/test/test_memoryio.py (original) > +++ python/branches/py3k/Lib/test/test_memoryio.py Mon Sep 6 20:48:21 > 2010 > @@ -384,7 +384,31 @@ > del __main__.PickleTestMemIO > > > -class PyBytesIOTest(MemoryTestMixin, MemorySeekTestMixin, unittest.TestCase): > +class BytesIOMixin: > + > + def test_getbuffer(self): > + memio = self.ioclass(b"1234567890") > + buf = memio.getbuffer() > + self.assertEqual(bytes(buf), b"1234567890") > + memio.seek(5) > + buf = memio.getbuffer() > + self.assertEqual(bytes(buf), b"1234567890") > + # Trying to change the size of the BytesIO while a buffer is exported > + # raises a BufferError. > + self.assertRaises(BufferError, memio.write, b'x' * 100) > + self.assertRaises(BufferError, memio.truncate) > + # Mutating the buffer updates the BytesIO > + buf[3:6] = b"abc" > + self.assertEqual(bytes(buf), b"123abc7890") > + self.assertEqual(memio.getvalue(), b"123abc7890") > + # After the buffer gets released, we can resize the BytesIO again > + del buf > + support.gc_collect() > + memio.truncate() I've raised an RFE (http://bugs.python.org/issue9789) to point out that the need for that GC collect call in there to make the test portable to other implementations is rather ugly and supporting an explicit "buf.release()" call may be a nicer option. (And added Guido to the nosy list, since he wasn't keen on supporting the context management protocol idea, but I don't believe he said anything one way or the other about an ordinary method). > +class PyBytesIOTest(MemoryTestMixin, MemorySeekTestMixin, > + BytesIOMixin, unittest.TestCase): I was going to ask why CBytesIOTest wasn't affected, but checking the full source of the test file made everything clear :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84559 - python/branches/py3k/Lib/subprocess.py
On Tue, Sep 7, 2010 at 2:29 AM, brian.curtin wrote:
> Author: brian.curtin
> Date: Mon Sep 6 18:29:29 2010
> New Revision: 84559
>
> Log:
> Fix #8956. ValueError message was only mentioning one signal.
>
> Rather than list out the three signals (or more over time), the message was
> made less specific but still descriptive.
>
>
>
> Modified:
> python/branches/py3k/Lib/subprocess.py
>
> Modified: python/branches/py3k/Lib/subprocess.py
> ==
> --- python/branches/py3k/Lib/subprocess.py (original)
> +++ python/branches/py3k/Lib/subprocess.py Mon Sep 6 18:29:29 2010
> @@ -983,7 +983,7 @@
> elif sig == signal.CTRL_BREAK_EVENT:
> os.kill(self.pid, signal.CTRL_BREAK_EVENT)
> else:
> - raise ValueError("Only SIGTERM is supported on Windows")
> + raise ValueError("Unsupported signal")
Would it be worth including the signal number here, to at least give
some hint as to exactly which signal was received?
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Write access to hg.python.org
Am 07.09.2010 10:29, schrieb Dirkjan Ochtman: > On Tue, Sep 7, 2010 at 10:11, Georg Brandl wrote: >> To be a bit more precise, having a public key on file for SVN commits is >> enough, > > Not exactly, hg uses a separate keystore, so it might not have some of > the newer keys. Oh ok, I thought they were both generated from the keys repo. >> and your URI is >> >> ssh://h...@hg.python.org/repos/benchmarks >> >> (That may change depending on the final setup, of course.) > > Yes, I think I'd prefer to just get rid of the /repos/ for the URLs > (which makes http and ssh more similar, for one thing). Makes sense. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Write access to hg.python.org
On Tue, Sep 7, 2010 at 10:11, Georg Brandl wrote: > To be a bit more precise, having a public key on file for SVN commits is > enough, Not exactly, hg uses a separate keystore, so it might not have some of the newer keys. > and your URI is > > ssh://h...@hg.python.org/repos/benchmarks > > (That may change depending on the final setup, of course.) Yes, I think I'd prefer to just get rid of the /repos/ for the URLs (which makes http and ssh more similar, for one thing). Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Write access to hg.python.org
On Tue, 07 Sep 2010 10:11:41 +0200 Georg Brandl wrote: > Am 07.09.2010 09:21, schrieb Dirkjan Ochtman: > > On Tue, Sep 7, 2010 at 01:04, Antoine Pitrou wrote: > >> What is needed in order to have write (i.e. push) access to the > >> hg.python.org repositories? > >> What are the URLs (for example for the "benchmarks" repository)? > > > > IIRC you just need to have your public key on there, and you'll have > > commit access for everything on hg.p.o. > > To be a bit more precise, having a public key on file for SVN commits is > enough, > and your URI is > > ssh://h...@hg.python.org/repos/benchmarks > > (That may change depending on the final setup, of course.) Thank you! cheers Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Write access to hg.python.org
Am 07.09.2010 09:21, schrieb Dirkjan Ochtman: > On Tue, Sep 7, 2010 at 01:04, Antoine Pitrou wrote: >> What is needed in order to have write (i.e. push) access to the >> hg.python.org repositories? >> What are the URLs (for example for the "benchmarks" repository)? > > IIRC you just need to have your public key on there, and you'll have > commit access for everything on hg.p.o. To be a bit more precise, having a public key on file for SVN commits is enough, and your URI is ssh://h...@hg.python.org/repos/benchmarks (That may change depending on the final setup, of course.) cheers, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Write access to hg.python.org
On Tue, Sep 7, 2010 at 01:04, Antoine Pitrou wrote: > What is needed in order to have write (i.e. push) access to the > hg.python.org repositories? > What are the URLs (for example for the "benchmarks" repository)? IIRC you just need to have your public key on there, and you'll have commit access for everything on hg.p.o. Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
