On 24/08/2011 5.31, Nick Coghlan wrote:
On Wed, Aug 24, 2011 at 5:19 AM, Steven D'Aprano wrote:
(Nor do we write filingsystem, governmentsystem, politicalsystem or
schoolsystem. This is English, not German.)
Personally, I think 'filesystem' is a portmanteau in the process of
coming into existe
On 8/23/2011 6:38 PM, Victor Stinner wrote:
> Le mardi 23 août 2011 00:14:40, Antoine Pitrou a écrit :
>> - You could try to run stringbench, which can be found at
>> http://svn.python.org/projects/sandbox/trunk/stringbench (*)
>> and there's iobench (the text mode benchmarks) in the Tools/iobe
On Tue, Aug 23, 2011 at 18:56, Victor Stinner
wrote:
>> kind=0 is used and public, it's PyUnicode_WCHAR_KIND. Is it still
>> necessary? It looks to be only used in PyUnicode_DecodeUnicodeEscape().
>
> If it can be removed, it would be nice to have kind in [0; 2] instead of kind
> in [1; 2], to be
On Wed, Aug 24, 2011 at 9:57 AM, Antoine Pitrou wrote:
> I don't have any personal preference. Previous discussions seemed to
> indicate people preferred IOError. But changing the implementation to
> OSError would be simple. I agree OSError feels slightly more right, as
> in more generic.
IIRC, t
On Tue, Aug 23, 2011 at 10:08, Antoine Pitrou wrote:
> Macros are useful to shield the abstraction from the implementation. If
> you access the members directly, and the unicode object is represented
> differently in some future version of Python (say e.g. with tagged
> pointers), your code doesn'
On Tue, Aug 23, 2011 at 18:27, Victor Stinner
wrote:
> I posted a patch to re-add it:
> http://bugs.python.org/issue12819#msg142867
Thank you for the patch! Note that this patch adds the fast path only
to the helper function which determines the length of the string and
the maximum character. T
Unless I hear any objections, I plan to adjust the current PEP
statuses as follows some time this weekend:
Move from Accepted to Finished:
389 argparse - New Command Line Parsing Module Bethard
391 Dictionary-Based Configuration For Logging Sajip
3108 Stan
On Tue, Aug 23, 2011 at 08:15, Antoine Pitrou wrote:
> So why would you need three separate implementation of the unrolled
> loop? You already have a macro named WRITE_FLEXIBLE_OR_WSTR.
The WRITE_FLEXIBLE_OR_WSTR macro does a check for kind and then
writes. Using this macro for the fast path wou
On Wed, Aug 24, 2011 at 5:19 AM, Steven D'Aprano wrote:
> Antoine Pitrou wrote:
>>
>> 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?
>
> It's a
On Mon, Aug 22, 2011 at 18:14, Antoine Pitrou wrote:
> - You could trim the debug results from the benchmark results, this may
> make them more readable.
Good point, I removed them from the wiki page.
On Tue, Aug 23, 2011 at 18:38, Victor Stinner
wrote:
> Le mardi 23 août 2011 00:14:40, Antoin
On 8/23/2011 9:21 AM, Victor Stinner wrote:
Le 23/08/2011 15:06, "Martin v. Löwis" a écrit :
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.
I would not vote for the PEP if it slows
On 8/23/2011 6:20 AM, "Martin v. Löwis" wrote:
Am 23.08.2011 11:46, schrieb Xavier Morel:
Mostly ascii is pretty common for western-european languages (French, for
instance, is probably 90 to 95% ascii). It's also a risk in english, when
the writer "correctly" spells foreign words (résumé and th
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 8/23/2011 2:46 PM, Brian Curtin wrote:
I don't care all that much but I'm reminded of the .NET
FileSystemWatcher class, so put me down for +0.5 on FileSystemError.
For other reasons, I am at lease +.5 for FileSystemError also.
--
Terry Jan Reedy
__
Le mercredi 24 août 2011 00:46:16, Victor Stinner a écrit :
> Le lundi 22 août 2011 20:58:51, Torsten Becker a écrit :
> > [1]: http://www.python.org/dev/peps/pep-0393
>
> state:
> lowest 2 bits (mask 0x03) - interned-state (SSTATE_*) as in 3.2
> next 2 bits (mask 0x0C) - form of str:
> 00 => rese
Le lundi 22 août 2011 20:58:51, Torsten Becker a écrit :
> [1]: http://www.python.org/dev/peps/pep-0393
state:
lowest 2 bits (mask 0x03) - interned-state (SSTATE_*) as in 3.2
next 2 bits (mask 0x0C) - form of str:
00 => reserved
01 => 1 byte (Latin-1)
10 => 2 byte (UCS-2)
11 => 4 byte (UCS-4);
nex
Le mardi 23 août 2011 00:14:40, Antoine Pitrou a écrit :
> - You could try to run stringbench, which can be found at
> http://svn.python.org/projects/sandbox/trunk/stringbench (*)
> and there's iobench (the text mode benchmarks) in the Tools/iobench
> directory.
Some raw numbers.
stringbenc
Le mardi 23 août 2011 00:14:40, Antoine Pitrou a écrit :
> 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
I am sending this review as the BDFOP for PEP 3151. I've read the PEP and
reviewed the python-dev discussion via Gmane. I have not reviewed the hg
branch where Antoine has implemented it.
I'm not quite ready to pronounce, but I do have some questions and comments.
First off, thanks to Antoine fo
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 taken by another thread (which
On Tue, Aug 23, 2011 at 8:46 PM, Barry Warsaw wrote:
> On Aug 23, 2011, at 08:39 PM, Ross Lagerwall wrote:
>
> >> 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
Antoine Pitrou pitrou.net> writes:
> 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?
+1 for FileSystemError as I, like others, don't regard "filesystem" as a
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 taken by another thread (which is quite common when
> debugging).
Indeed.
To solve this, a similar mechanism
Antoine Pitrou wrote:
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?
It's a file system (two words), not filesystem (not in any dictionary or
spell ch
Barry Warsaw wrote:
> My online dictionaries prefer "file system" to be two words, so for me,
> FileSystemError is preferred.
+1
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubs
Antoine Pitrou wrote:
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?
FileSystemError
___
Python-Dev mailing
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
On Aug 23, 2011, at 08:39 PM, Ross Lagerwall wrote:
>> 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?
>
>I don't think it really matters since both "file sy
On Tue, Aug 23, 2011 at 13:20, Antoine Pitrou wrote:
>
> 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
On Tue, Aug 23, 2011 at 8:39 PM, Ross Lagerwall wrote:
>> 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?
I think "FilesystemError" looks nicer, but it's no
2011/8/23, Nir Aides :
> Hi all,
Hello Nir,
> 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 locks, but it'll at least make room
> 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?
I don't think it really matters since both "file system" and
"filesystem" appear to be in common usage.
I wo
On Tue, Aug 23, 2011 at 20:20, Antoine Pitrou wrote:
> 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?
FilesystemError.
Cheers,
--
Sandro Tosi (aka morph, m
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.
_
Hi all,
Please consider this invitation to stick your head into an interesting
problem:
http://bugs.python.org/issue6721
Nir
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.p
> Even with tagged pointers, you could just provide a macro that unpacks
> the pointer to the buffer for a given string kind.
These macros are indeed available.
> I don't think there's
> much more to be done to keep up the abstraction. I don't see a reason to
> prevent users from accessing the me
Antoine Pitrou, 23.08.2011 16:08:
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 th
On Tue, Aug 23, 2011 at 11:21 PM, Victor Stinner
wrote:
> Le 23/08/2011 15:06, "Martin v. Löwis" a écrit :
>>
>> 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.
>
> I would not
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
On Tue, Aug 23, 2011 at 11:17 PM, "Martin v. Löwis" wrote:
>> 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 the kind, in which case it even
> stopped be
"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 the kind, in which case it even
stopped being a pointer. Modules are not
Le 23/08/2011 15:06, "Martin v. Löwis" a écrit :
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.
I would not vote for the PEP if it slows down Python, especially if it's
much slower.
> 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
> 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 the kind, in which case it even
stopped being a pointer. Modules are not expected to access this
pointer excep
> So why would you need three separate implementation of the unrolled
> loop? You already have a macro named WRITE_FLEXIBLE_OR_WSTR.
Depending on where the speedup comes from in this optimization, it
may well be that the overhead of figuring out where to store the
result eats the gain from the fas
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
Torsten Becker, 22.08.2011 20:58:
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 bug tracker [2]. I posted documentation fo
> 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?
> Do you have three copies of the UTF-8 decoder already, or do you a use a
> stringlib-like approach?
It's a single implementation - see for yourself.
> >> 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
Am 23.08.2011 11:46, schrieb Xavier Morel:
> On 2011-08-23, at 10:55 , Martin v. Löwis wrote:
>>> - “The UTF-8 decoding fast path for ASCII only characters was removed
>>> and replaced with a memcpy if the entire string is ASCII.”
>>> The fast path would still be useful for mostly-ASCII strings,
On 2011-08-23, at 10:55 , Martin v. Löwis wrote:
>> - “The UTF-8 decoding fast path for ASCII only characters was removed
>> and replaced with a memcpy if the entire string is ASCII.”
>> The fast path would still be useful for mostly-ASCII strings, which
>> are extremely common (unless UTF-8 ha
"Martin v. Löwis", 23.08.2011 10:55:
- “The UTF-8 decoding fast path for ASCII only characters was removed
and replaced with a memcpy if the entire string is ASCII.”
The fast path would still be useful for mostly-ASCII strings, which
are extremely common (unless UTF-8 has become a no-op?
> - “The UTF-8 decoding fast path for ASCII only characters was removed
> and replaced with a memcpy if the entire string is ASCII.”
> The fast path would still be useful for mostly-ASCII strings, which
> are extremely common (unless UTF-8 has become a no-op?).
Is it really extremely common
Torsten Becker, 22.08.2011 20:58:
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 bug tracker [2]. I posted documentation fo
54 matches
Mail list logo
