Paul Moore gmail.com> writes:
> >
> > As I pointed out, utf-8, utf-16 and latin1 decoders have already been
optimized
> > in py3k. For *pure ASCII* input, utf-8 decoding is blazingly fast (1GB/s
here).
> > The dataset for iobench isn't pure ASCII though, and that's why it's not
as fast.
>
> Ah, t
Le mercredi 28 janvier 2009 à 16:54 +, Paul Moore a écrit :
> I do think it's worth taking care over the default encoding, though.
> Quite apart from performance, getting "correct" behaviour is
> important. I can't speak for Unix, but on Windows, the following
> behaviour feels like a bug to me
Thomas Heller ctypes.org> writes:
>
> To test this functionality it is required to add some C++ source code to the
> ctypes private test module _ctypes_test.pyd/_ctypes_test.so.
Perhaps you should create a separate test module (_ctypes_pp_test?) so that
platforms without a properly configured C+
Hello,
Ben North redfrontdoor.org> writes:
>
> I find 'functools.partial' useful, but occasionally I'm unable to use it
> because it lacks a 'from the right' version. E.g., to create a function
> which splits a string on commas, you can't say
>
># Won't work when called:
>split_comma
Scott David Daniels Acm.Org> writes:
>
> Antoine Pitrou wrote:
> > ...
> > In py3k, we could also use "..." (the Ellipsis object) to denote
> > places where an argument is missing, so that:
> > split_comma = partial(str.split, ..., ',')
Alexander Belopolsky gmail.com> writes:
>
> By this analogy, partial(f, ..., *args) is right_partial with '...'
> standing for any number of missing arguments. I you want to specify
> exactly one missing argument, you would want to write partial(f, :,
> *args), which is not a valid syntax even i
Nick Coghlan gmail.com> writes:
>
> If partial starts messing about looking for missing arguments and then
> slotting them in, then it is likely to slow down to the point where you
> would be better off skipping it and writing a dedicated function that
> adds the extra arguments.
Looking for mis
Raymond Hettinger rcn.com> writes:
>
> * If you're thinking that shelves have very few users and that
> 3.0.0 has had few adopters, doesn't that mitigate the effects
> of making a better format available in 3.0.1? Wouldn't this
> be the time to do it?
There was already another proposal fo
Raymond Hettinger rcn.com> writes:
>
> P.S. My other experience with 3.0 is that my most frequent error has
> changed. It used to be that the number reason for my getting a syntax
> error was leaving-off a colon. Now, my number one reason is
> omitting parens in a print() function call. I tho
Aahz pythoncraft.com> writes:
>
> There's absolutely no reason not to have a 3.0.2 before 3.1 comes out.
> You're probably right that what Raymond wants to is best not done for
> 3.0.1 -- but once we've agreed in principle that 3.0.x isn't a true
> production release of Python for PEP6 purposes,
Nick Coghlan gmail.com> writes:
>
> Doing "svn resolved ." assumes that you did everything else correctly,
> and even then I don't see how svnmerge could both backport the py3k
> changes to the metadata and make its own changes and still get the
> metadata to a sane state.
The metadata are discr
Calvin Spealman gmail.com> writes:
>
> I am just replying to the end of this thread to throw in a reminder
> about my partial.skip patch, which allows the following usage:
>
> split_one = partial(str.split, partial.skip, 1)
>
> Not looking to say "mine is better", but if the idea is being given
Martin v. Löwis v.loewis.de> writes:
>
> > Any thoughts? My own opinion is that it really doesn't matter
> > that much if the slot is left in; it's just a little annoying to have
> > such backwards-compatibility baggage already present in
> > the shiny new 3.0 series. A little like finding a b
Bill Janssen parc.com> writes:
>
> is OpenSSL 64-bit clean?
I'm afraid I'm completely incompetent on this subject...!
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Collin Winter gmail.com> writes:
>
> Have any of the original objections to Calvin's patch
> (http://bugs.python.org/issue1706256) been addressed? If not, I don't
> see anything in these threads that justify resurrecting it.
>
> I still haven't seen any real code presented that would benefit fro
Hello,
> I agree. The best thing to do would be to deprecate the Python wrappers
> around insecure C functions and then remove them after a couple releases.
They have been removed in 3.0.
> Why does Python offer
> this attractive nuisance?
Well, there was a time when security concerns were a
Jaroslav Pachola mageo.cz> writes:
>
> What's the replacement in the library then, in case that I just want to
> create
> a unique file name and I don't care about the possible issues?
Three alternatives I'm thinking of:
- tempfile.mktemp(): the doc says it has been deprecated since 2.3, but i
Greg Ewing canterbury.ac.nz> writes:
>
> I've no problem with using 'yield' when actually
> giving up control. But the code making the call doesn't
> think of itself as yielding. The called code may
> want to yield, but the caller doesn't care about
> that. It just wants to make the callee do its
On Sat, 30 Jul 2011 23:47:36 -0700
Raymond Hettinger wrote:
> >
> > (Also, there must have been some reason to make "..." available everywhere
> > for Python 3.)
> >
>
> It's really nice for stub functions:
>
> def foo(x):
> ...
Using a docstring looks a lot less hackish (and it encourage
On Sun, 31 Jul 2011 18:26:42 +1000
Nick Coghlan wrote:
> On Sun, Jul 31, 2011 at 9:09 AM, nadeem.vawda
> wrote:
> > http://hg.python.org/cpython/rev/b76684d62a8d
> > changeset: 71645:b76684d62a8d
> > user: Nadeem Vawda
> > date: Sun Jul 31 01:09:04 2011 +0200
> > summary:
> > I
On Sun, 31 Jul 2011 17:17:00 +0100
Michael Foord wrote:
> > I found that [, timeout] bit odd too. But is not mentioning that as
> > timeout=None when it is timeout=socket._GLOBAL_DEFAULT_TIME
> > technically inaccurate?
> >
>
> It does mean that users will expect to be able to call with an expli
On Tue, 02 Aug 2011 12:33:55 +0200
senthil.kumaran wrote:
> raise TypeError("data should be a bytes-like object\
> -or an iterable, got %r " % type(it))
> +or an iterable, got %r " % type(data))
There are still a lot of spaces in yo
On Wed, 03 Aug 2011 00:30:41 +0200
benjamin.peterson wrote:
>
> diff --git a/Misc/NEWS b/Misc/NEWS
> --- a/Misc/NEWS
> +++ b/Misc/NEWS
> @@ -10,6 +10,8 @@
> Core and Builtins
> -
>
> +- Add ThreadError to threading.__all__.
> +
This should surely be in the library section.
R
On Wed, 03 Aug 2011 12:47:23 +0200
senthil.kumaran wrote:
>
> diff --git a/Lib/test/test_urlparse.py b/Lib/test/test_urlparse.py
> --- a/Lib/test/test_urlparse.py
> +++ b/Lib/test/test_urlparse.py
> @@ -371,6 +371,8 @@
> self.checkJoin('http:///', '..','http:///')
> self.checkJo
On Thu, 4 Aug 2011 15:54:54 +1000
Nick Coghlan wrote:
> On Thu, Aug 4, 2011 at 3:42 PM, Georg Brandl wrote:
> > Am 04.08.2011 05:25, schrieb solip...@pitrou.net:
> >> results for 65c412586901 on branch "default"
> >>
> >>
> >>
> >>
> >> Command line wa
On Fri, 5 Aug 2011 09:01:01 -0400 (EDT)
"Robert P. J. Day" wrote:
>
> this build process works just fine for everyone else on the planet
> but it fails for me because i'm doing something apparently no one else
> has tried -- i'm running a (hand-rolled) linux 3.x kernel on my build
> host and it
On Fri, 5 Aug 2011 17:55:33 -0400
Jim Jewett wrote:
> Why was the old test suite removed?
>
> Even if everything is covered by the test file (and that isn't clear
> from this checkin), I don't see anything wrong with a quick test that
> doesn't require loading the whole testing apparatus. (I wou
Le Wed, 10 Aug 2011 14:54:33 -0500,
Benjamin Peterson a écrit :
> 2011/8/10 Brian Curtin :
> > Now that we have concurrent.futures, is there any plan for
> > multiprocessing to follow suit? PEP 3148 mentions a hope to add or move
> > things in the future
>
> Is there some sort of concrete proposa
Le Thu, 11 Aug 2011 03:34:37 +0200,
brian.curtin a écrit :
> http://hg.python.org/cpython/rev/77a65b078852
> changeset: 71809:77a65b078852
> parent: 71803:1b4fae183da3
> user:Brian Curtin
> date:Wed Aug 10 20:05:21 2011 -0500
> summary:
> Add Py_RETURN_NOTIMPLEMENTED macr
Le Thu, 11 Aug 2011 09:03:35 +1000,
Nick Coghlan a écrit :
> On Thu, Aug 11, 2011 at 4:55 AM, Brian Curtin
> wrote:
> > Now that we have concurrent.futures, is there any plan for
> > multiprocessing to follow suit? PEP 3148 mentions a hope to add or move
> > things in the future [0], which would
On Thu, 11 Aug 2011 11:39:52 -0400
Barry Warsaw wrote:
> On Aug 11, 2011, at 04:39 PM, Éric Araujo wrote:
>
> >> * XXX what is the __file__ of a "pure virtual" package? ``None``?
> >> Some arbitrary string? The path of the first directory with a
> >> trailing separator? No matter what we
suggest any additions.
Regards
Antoine.
http://www.python.org/dev/peps/pep-3154/
PEP: 3154
Title: Pickle protocol version 4
Version: $Revision$
Last-Modified: $Date$
Author: Antoine Pitrou
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2011-08-11
Python-Version: 3.3
Post
Hello,
Le vendredi 12 août 2011 à 14:32 +0200, Xavier Morel a écrit :
> On 2011-08-12, at 12:58 , Antoine Pitrou wrote:
> > Current protocol versions export object sizes for various built-in types
> > (str, bytes) as 32-bit ints. This forbids serialization of large data
> &
On Fri, 12 Aug 2011 09:32:23 -0500
VanL wrote:
> On 8/11/2011 2:11 PM, Sturla Molden wrote:
> >
> > (b) another threading model (e.g. one interpreter per thread, as in Tcl,
> > Erlang, or .NET app domains).
>
> We are close to this, in that we already have baked-in support for
> subinterpreters.
On Sat, 13 Aug 2011 09:08:16 -0400
Guido van Rossum wrote:
>
> And, though mostly off-topic, the worst problem with C code, calling
> back into Python, and the GIL that I have seen (several times):
> Suppose you are calling some complex C library that creates threads
> itself, where those threads
On Sat, 13 Aug 2011 19:08:40 -0400
Doug Hellmann wrote:
>
> Charles McLaughlin of Atlassian has set up mirrors of the Mercurial
> repositories hosted on python.org as part of the ongoing infrastructure
> improvement work. These mirrors will give us a public fail-over repository in
> the event
Le lundi 15 août 2011 à 13:16 +1000, Nick Coghlan a écrit :
> On Mon, Aug 15, 2011 at 12:34 PM, Brett Cannon wrote:
> > On Thu, Aug 11, 2011 at 00:02, Antoine Pitrou wrote:
> >> It would sound more useful to have a generic Py_RETURN() macro rather than
> >> some specif
On Mon, 15 Aug 2011 05:46:12 -0700
Raymond Hettinger wrote:
>
> I don't think that is worth it.
> There is some value to keeping the API consistent with the style that has
> been used in the past.
> So, I vote for Py_RETURN_NOTIMPLEMENTED. There's no real need to factor this
> any further.
> I
On Mon, 15 Aug 2011 15:21:43 +0200
Stefan Behnel wrote:
> Nick Coghlan, 15.08.2011 14:35:
> > On Mon, Aug 15, 2011 at 10:17 PM, Antoine Pitrou
> > wrote:
> >> AFAICT, often with True and False:
> >>
> >> x = (some condition) ? Py_True : Py_False
On Mon, 15 Aug 2011 09:49:43 -0400
Barry Warsaw wrote:
> On Aug 15, 2011, at 05:46 AM, Raymond Hettinger wrote:
>
> >I don't think that is worth it. There is some value to keeping the API
> >consistent with the style that has been used in the past. So, I vote for
> >Py_RETURN_NOTIMPLEMENTED. T
On Tue, 16 Aug 2011 12:35:48 +1000
Nick Coghlan wrote:
> On Tue, Aug 16, 2011 at 11:30 AM, antoine.pitrou
> wrote:
> > +Serializing "pseudo-global" objects
> > +---
> > +
> > +Objects which are not module-global, but should be treated in a similar
> > +fashion -- s
On Tue, 16 Aug 2011 20:15:51 +1000
Nick Coghlan wrote:
> >
> > Oops, I admit I hadn't read PEP 395.
> > PEP 395 focuses on module aliasing, while the suggestion above focuses
> > on the path of objects in modules. How can we reconcile the two? Do we
> > want __qualname__ to be a relative "path" in
On Thu, 18 Aug 2011 09:16:21 + (UTC)
Vinay Sajip wrote:
> Tarek Ziadé gmail.com> writes:
>
> > Ideally, if you could push this to hg.python.org/distutils2
> > (overwriting the existing stuff).
>
> Okay, done. I've overwritten existing files and added new ones, only
> removing/renaming thing
On Thu, 18 Aug 2011 18:22:54 +0200
Stefan Krah wrote:
>
> So, memoryview does exactly the opposite of what is specified. It should
> reject the bytes object but accept the integer.
Well, memoryview is quite dumb right now. It ignores the format and
just considers its underlying memory a bytes se
On Thu, 18 Aug 2011 17:49:28 +0200
benjamin.peterson wrote:
> -PyErr_SetString(PyExc_TypeError, "embedded NUL character");
> +PyErr_SetString(PyExc_TypeError, "embedded NULL character");
Are you sure? IIRC, NUL is the little name of ASCII character 0
(while NULL would be the NULL
On Thu, 18 Aug 2011 18:57:00 +0200
Stefan Krah wrote:
>
> Oh no, the name isn't quite right then. It should be a replacement
> for the combination PyBuffer_FillInfo()/PyMemoryView_FromBuffer()
> and it should temporarily wrap a C-string.
Ah, nice.
> PyObject * PyMemoryView_FromCString(char *s,
On Sat, 20 Aug 2011 07:58:13 -0300
Facundo Batista wrote:
>
> This is ok, I expected this. However, note what happens if I send unicode:
>
> >>> s.sendto('data', ('localhost', 3))
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: sendto() takes exactly 3 arguments (2 giv
Hello,
On Mon, 22 Aug 2011 14:58:51 -0400
Torsten Becker wrote:
>
> I have implemented an initial version of PEP 393 -- "Flexible String
> Representation" as part of my Google Summer of Code project. My patch
> is hosted as a repository on bitbucket [1] and I created a related
> issue on the b
On Mon, 22 Aug 2011 19:31:32 +0200
ezio.melotti wrote:
> http://hg.python.org/cpython/rev/06b30c5bcc3d
> changeset: 72035:06b30c5bcc3d
> branch: 3.2
> parent: 72026:c8e73a89150e
> user:Ezio Melotti
> date:Mon Aug 22 14:08:38 2011 +0300
> summary:
> #9200: The str.is*
> >> Is it really extremely common to have strings that are mostly-ASCII but
> >> not completely ASCII? I would agree that pure ASCII strings are
> >> extremely common.
> > Mostly ascii is pretty common for western-european languages (French, for
> > instance, is probably 90 to 95% ascii). It's al
Le mardi 23 août 2011 à 13:51 +0200, "Martin v. Löwis" a écrit :
> > This optimization was done when trying to improve the speed of text I/O.
>
> So what speedup did it achieve, for the kind of data you talked about?
Since I don't have the number anymore, I've just saved the contents of
https://l
> Well, things have to be done in order:
> 1. the PEP needs to be approved
> 2. the performance bottlenecks need to be identified
> 3. optimizations should be applied.
Sure, but the whole point of the PEP is to improve performance (I am
dumping "memory consumption" in the "performance" bucket). T
On Tue, 23 Aug 2011 16:02:54 +0200
Stefan Behnel wrote:
> "Martin v. Löwis", 23.08.2011 15:17:
> >> Has this been considered before? Was there a reason to decide against it?
> >
> > I think we simply didn't consider it. An early version of the PEP used
> > the lower bits for the pointer to encode
Hello,
When reviewing the PEP 3151 implementation (*), Ezio commented that
"FileSystemError" looks a bit strange and that "FilesystemError" would
be a better spelling. What is your opinion?
(*) http://bugs.python.org/issue12555
Thank you
Antoine.
_
On Tue, 23 Aug 2011 20:43:25 +0200
Charles-François Natali wrote:
> > Please consider this invitation to stick your head into an interesting
> > problem:
> > http://bugs.python.org/issue6721
>
> Just for the record, I'm now in favor of the atfork mechanism. It
> won't solve the problem for I/O lo
Le mardi 23 août 2011 à 22:07 +0200, Charles-François Natali a écrit :
> 2011/8/23 Antoine Pitrou :
> > Well, I would consider the I/O locks the most glaring problem. Right
> > now, your program can freeze if you happen to do a fork() while e.g.
> > the stderr lock is ta
Hi,
> One guiding principle for me is that we should keep the abstraction as thin as
> possible. In particular, I'm concerned about mapping multiple errnos into a
> single Error. For example both EPIPE and ESHUTDOWN mapping to BrokePipeError,
> or EACESS or EPERM to PermissionError. I think we
On Thu, 25 Aug 2011 01:34:17 +0900
"Stephen J. Turnbull" wrote:
>
> Martin has long claimed that the fact that I/O is done in terms of
> UTF-16 means that the internal representation is UTF-16
Which I/O?
___
Python-Dev mailing list
Python-Dev@python
On Wed, 24 Aug 2011 15:31:50 +0200
Charles-François Natali wrote:
> > The buildbots are complaining about some of tests for the new
> > socket.sendmsg/recvmsg added by issue #6560 for *nix platforms that
> > provide CMSG_LEN.
>
> Looks like kernel bugs:
> http://developer.apple.com/library/mac/#q
Le jeudi 25 août 2011 à 02:15 +0900, Stephen J. Turnbull a écrit :
> Antoine Pitrou writes:
> > On Thu, 25 Aug 2011 01:34:17 +0900
> > "Stephen J. Turnbull" wrote:
> > >
> > > Martin has long claimed that the fact that I/O is done in ter
On Wed, 24 Aug 2011 20:15:24 +0200
"Martin v. Löwis" wrote:
> - issues to be considered (unclarities, bugs, limitations, ...)
With this PEP, the unicode object overhead grows to 10 pointer-sized
words (including PyObject_HEAD), that's 80 bytes on a 64-bit machine.
Does it have any adverse effects
On Wed, 24 Aug 2011 11:37:20 -0700
Ned Deily wrote:
> In article <20110824184927.2697b...@pitrou.net>,
> Antoine Pitrou wrote:
> > On Wed, 24 Aug 2011 15:31:50 +0200
> > Charles-François Natali wrote:
> > > > The buildbots are complaining about some of test
Hello,
On Thu, 25 Aug 2011 10:24:39 +0200
"Martin v. Löwis" wrote:
>
> On a 32-bit machine with a 32-bit wchar_t, pure-ASCII strings of length
> 1 (+NUL) will take the same memory either way: 8 bytes for the
> characters in 3.2, 2 bytes in 3.3 + extra pointer + padding. Strings
> of 2 or more c
Why would PEP 393 apply to other implementations than CPython?
Regards
Antoine.
On Fri, 26 Aug 2011 00:01:42 +
Dino Viehland wrote:
> Guido wrote:
> > Which reminds me. The PEP does not say what other Python
> > implementations besides CPython should do. presumably Jython and
> > IronPyt
On Fri, 26 Aug 2011 14:52:07 +1000
Nick Coghlan wrote:
> Windows is a developer hostile platform unless you completely buy into
> the Microsoft toolchain, which is not an option for cross-platform
> projects like Python.
We already buy into the MS toolchain since we require Visual Studio (or
at l
Hi,
> I think that "deprecating" the use of threads w/ multiprocessing - or
> at least crippling it is the wrong answer. Multiprocessing needs the
> helper threads it uses internally to manage queues, etc. Removing that
> ability would require a near-total rewrite, which is just a
> non-starter.
On Fri, 26 Aug 2011 15:18:35 -0700
Guido van Rossum wrote:
>
> I can't say I liked how that transition was handled last time around.
> I really don't want to have to tell people "Oh, that bug is fixed but
> you have to use regex instead of re" and then a few years later have
> to tell them "Oh, w
On Fri, 26 Aug 2011 15:47:21 -0700
Guido van Rossum wrote:
> > The best way would be to contact the author, Matthew Barnett,
>
> I had added him to the beginning of this thread but someone took him off.
>
> > or to ask
> > on the tracker on http://bugs.python.org/issue2636. He has been quite
> >
On Sat, 27 Aug 2011 01:00:31 +0200
"M.-A. Lemburg" wrote:
> >
> > I can't say I liked how that transition was handled last time around.
> > I really don't want to have to tell people "Oh, that bug is fixed but
> > you have to use regex instead of re" and then a few years later have
> > to tell th
On Fri, 26 Aug 2011 15:48:42 -0700
Dan Stromberg wrote:
>
> Then there probably should be a from __future__ import for a while.
If you are willing to use a "from __future__ import", why not simply
import regex as re
? We're not Perl, we don't have built-in syntactic support for regular
exp
On Sat, 27 Aug 2011 12:17:18 +1200
Greg Ewing wrote:
> Paul Moore wrote:
>
> > IronPython and Jython can retain UTF-16 as their native form if that
> > makes interop cleaner, but in doing so they need to ensure that basic
> > operations like indexing and len work in terms of code points, not
> >
On Sat, 27 Aug 2011 04:37:21 +0300
Ezio Melotti wrote:
>
> I'm not sure it's worth doing an extensive review of the code, a better
> approach might be to require extensive test coverage (and a review of
> tests). If the code seems well written, commented, documented (I think
> proper rst docume
On Fri, 26 Aug 2011 17:25:56 -0700
Dan Stromberg wrote:
> On Fri, Aug 26, 2011 at 5:08 PM, Antoine Pitrou wrote:
>
> > On Fri, 26 Aug 2011 15:48:42 -0700
> > Dan Stromberg wrote:
> > >
> > > Then there probably should be a from __future__ import for a while.
On Sat, 27 Aug 2011 09:18:14 +0200
"Martin v. Löwis" wrote:
> Am 27.08.2011 08:33, schrieb Terry Reedy:
> > On 8/26/2011 9:56 PM, Antoine Pitrou wrote:
> >
> >> Another "interesting" question is whether it's easy to port to the PEP
&g
On Sat, 27 Aug 2011 08:02:31 +0200
"Martin v. Löwis" wrote:
> > I'm not sure it's worth doing an extensive review of the code, a better
> > approach might be to require extensive test coverage (and a review of
> > tests).
>
> I think it's worth. It's really bad if only one developer fully
> unde
On Sat, 27 Aug 2011 15:08:36 +0200
Armin Rigo wrote:
> Hi Nick,
>
> On Sat, Aug 27, 2011 at 2:40 PM, Nick Coghlan wrote:
> > 1. How does the patch interact with C code that explicitly releases
> > the GIL? (e.g. IO commands inside a "with atomic:" block)
>
> As implemented, any code in a "with
On Sun, 28 Aug 2011 01:36:50 +1000
Nick Coghlan wrote:
> On Sun, Aug 28, 2011 at 1:15 AM, "Martin v. Löwis" wrote:
> > This is exactly what I worry about. I think adding file I/O to bz2 was a
> > mistake, as this doesn't integrate with Python's IO library (it used
> > to, but now after dropping s
On Sun, 28 Aug 2011 01:52:51 +1000
Nick Coghlan wrote:
> >
> > The plausible story being that we basically wrap an existing library?
> > I don't think PyPy et al have pure Python versions of the zlib or
> > OpenSSL, do they?
> >
> > If we start taking PEP 399 conformance to such levels, we might a
On Sat, 27 Aug 2011 18:50:40 +0200
Antoine Pitrou wrote:
> On Sun, 28 Aug 2011 01:52:51 +1000
> Nick Coghlan wrote:
> > >
> > > The plausible story being that we basically wrap an existing library?
> > > I don't think PyPy et al have pure Python versions
On Sat, 27 Aug 2011 15:14:15 -0700
Dan Stromberg wrote:
> On Sat, Aug 27, 2011 at 2:38 PM, Nadeem Vawda wrote:
>
> > On Sat, Aug 27, 2011 at 10:41 PM, Dan Stromberg
> > wrote:
> > > It seems like there should be some way of coming up with an xml file
> > > describing the types of the various bi
On Sat, 27 Aug 2011 16:19:01 -0700
Dan Stromberg wrote:
> 2) It's a rather arbitrary distinction that's being drawn between dev and
> nondev today. There's no particular reason why the line couldn't be drawn
> somewhere else.
Sure. Now please convince Linux distributions first, because this
part
On Sun, 28 Aug 2011 20:13:11 +0200
martin.v.loewis wrote:
>
> +Performance
> +---
> +
> +Performance of this patch must be considered for both memory
> +consumption and runtime efficiency. For memory consumption, the
> +expectation is that applications that have many large strings will s
> - the iobench results are between 2% acceleration (seek operations),
> 16% slowdown for small-sized reads (4.31MB/s vs. 5.22 MB/s) and
> 37% for large sized reads (154 MB/s vs. 235 MB/s). The speed
> difference is probably in the UTF-8 decoder; I have already
> restored the "runs of ASCI
Le dimanche 28 août 2011 à 22:23 +0200, "Martin v. Löwis" a écrit :
> Am 28.08.2011 22:01, schrieb Antoine Pitrou:
> >
> >> - the iobench results are between 2% acceleration (seek operations),
> >> 16% slowdown for small-sized reads (4.31MB/s vs. 5.22 MB/s)
On Mon, 29 Aug 2011 12:43:24 +0900
"Stephen J. Turnbull" wrote:
>
> Since when can s[0] represent a code point outside the BMP, for s a
> Unicode string in a narrow build?
>
> Remember, the UCS-2/narrow vs. UCS-4/wide distinction is *not* about
> what Python supports vs. the outside world. It's
On Sun, 28 Aug 2011 09:43:33 -0700
Guido van Rossum wrote:
>
> This sounds like a very interesting idea to pursue, even if it's late,
> and even if it's experimental, and even if it's possible to cause
> deadlocks (no news there). I propose that we offer a C API in Python
> 3.3 as well as an exte
On Mon, 29 Aug 2011 18:38:23 +0200
Dirkjan Ochtman wrote:
> On Mon, Aug 29, 2011 at 18:24, Barry Warsaw wrote:
> >>Also, this PEP makes me wonder if there should be a way to distinguish
> >>between language PEPs and (CPython) implementation PEPs, by adding a
> >>tag or using the PEP number ranges
On Mon, 29 Aug 2011 13:03:53 -0400
Jesse Noller wrote:
> 2011/8/29 Charles-François Natali :
> >> +3 (agreed to Jesse, Antoine and Ask here).
> >> The http://bugs.python.org/issue8713 described "non-fork" implementation
> >> that always uses subprocesses rather than plain forked processes is the
Le lundi 29 août 2011 à 13:23 -0400, Jesse Noller a écrit :
>
> Yes, it is annoying; but again - this makes it more consistent with
> the windows implementation. I'd rather that restriction than the
> "sanitization" of the ability to use threading and multiprocessing
> alongside one another.
That
On Mon, 29 Aug 2011 22:32:01 +0200
"Martin v. Löwis" wrote:
> I have now written a Django application to measure the effect of PEP
> 393, using the debug mode (to find all strings), and sys.getsizeof:
>
> https://bitbucket.org/t0rsten/pep-393/src/ad02e1b4cad9/pep393utils/djmemprof/count/views.py
On Mon, 29 Aug 2011 11:33:14 -0700
stefan brunthaler wrote:
> * The optimized dispatch routine has a changed instruction format
> (word-sized instead of bytecodes) that allows for regular instruction
> decoding (without the HAS_ARG-check) and inlinind of some objects in
> the instruction format on
On Mon, 29 Aug 2011 17:18:33 -0400
Barry Warsaw wrote:
> On Aug 24, 2011, at 01:57 AM, Antoine Pitrou wrote:
>
> >> One guiding principle for me is that we should keep the abstraction as thin
> >> as possible. In particular, I'm concerned about mapping multiple er
On Tue, 30 Aug 2011 10:00:28 +1000
Nick Coghlan wrote:
> >
> > Having a word-sized "bytecode" format would probably be acceptable in
> > itself, so if you want to submit a patch for that, go ahead.
>
> Although any such patch should discuss how it compares with Cesare's
> work on wpython.
> Perso
By the way, I don't know if you're working on it, but StringIO seems a
bit broken right now. test_memoryio crashes here:
test_newline_cr (test.test_memoryio.CStringIOTest) ... Fatal Python error:
Segmentation fault
Current thread 0x7f3f6353b700:
File "/home/antoine/cpython/pep-393/Lib/tes
On Tue, 30 Aug 2011 13:29:59 +1000
Nick Coghlan wrote:
>
> Anecdotal, non-reproducible performance figures are *not* the way to
> go about serious optimisation efforts.
What about anecdotal *and* reproducible performance figures? :)
I may be half-joking, but we already have a set of py3k-compati
On Tue, 30 Aug 2011 16:22:14 +0200
eric.araujo wrote:
> http://hg.python.org/cpython/rev/af0bcccb935b
> changeset: 72127:af0bcccb935b
> user:Éric Araujo
> date:Tue Aug 30 00:55:02 2011 +0200
> summary:
> Remove display options (--name, etc.) from the Distribution class.
>
>
> The problem with a narrow build (whether for space efficiency in
> CPython or for platform compatibility in Jython and IronPython) is not
> that we have no UTF-16 codecs. It's that array ops aren't UTF-16
> conformant.
Sorry, what is a conformant UTF-16 array op?
Thanks
Antoine.
__
On Tue, 30 Aug 2011 08:27:13 -0700
stefan brunthaler wrote:
> >> Changing the bytecode width wouldn't make the interpreter more complex.
> >
> > No, but I think Stefan is proposing to add a *second* byte code format,
> > in addition to the one that remains there. That would certainly be an
> > inc
Le jeudi 01 septembre 2011 à 08:45 -0700, Guido van Rossum a écrit :
> This is definitely thought of as a separate
> mark added to the e; ë is not a new letter. I have a feeling it's the
> same way for the French and Germans, but I really don't know.
> (Antoine? Georg?)
Indeed, they are not separa
> The example given was someone who didn't agree with how a particular
> font rendered those accented characters. I agree that's obscure
> though.
>
> I recall long ago that when the french wrote words in all caps they
> would drop the accents, e.g. ECOLE. I even recall (through the mists
> of ti
4001 - 4100 of 4909 matches
Mail list logo
