Hello people,
Looking at http://www.python.org/dev/buildbot/, we are still missing buildbots
for the release26-maint and release30-maint branches. Is someone working on
that?
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http
Benjamin Peterson gmail.com> writes:
>
> Since the release of 3.0, several critical issues have come to our
> attention. Namely, the builtin cmp function wasn't removed [1] and the
> new IO library proved to be (as expected) abysmally slow [2][3][4].
> Christian proposed that we release 3.0.1 wit
Nick Coghlan gmail.com> writes:
>
> If the binary APIs are missing from a major platform (i.e. Windows) then
> the choice to use them brings with it a major cross-platform portability
> problem that should really be handled by the standard library.
+1
I might also add that providing binary APIs
Hello,
The Py_buffer struct has two pointers named `shape` and `strides`. Each points
to an array of Py_ssize_t values whose length is equal to the number of
dimensions of the buffer object. Unfortunately, the buffer protocol spec doesn't
explain how allocation of these arrays should be handled.
Nick Coghlan gmail.com> writes:
>
> Where would adding a (undocumented) get_filename() method to ZipImporter
> objects for the benefit of the -m switch fit then?
Why not call it _get_filename() in 3.0 and get_filename() in 3.1?
___
Python-Dev mailin
M.-A. Lemburg egenix.com> writes:
>
> Such application specific error handlers could then also apply
> whatever fancy round-trip safe encoding of non-decodable bytes
> to Unicode escapes, private code points, etc. as seen fit by the
> application.
I'd argue that such fancy round-trip safe error
Nick Coghlan gmail.com> writes:
>
> Actually, I think your suggested scheme for the one-dimensional case
> shows the way forward: ownership of the shape and strides memory belongs
> to the object issuing the Py_buffer struct, and that object needs to
> deal with it when the buffer is released. De
Adam Olsen gmail.com> writes:
>
> Except they're clearly NOT part of the unicode spec.
This is always the same discussion going in circles. I know they're not part of
the unicode spec, but practicality beats purity and if the said error handler
comes with an appropriate warning in the official d
Nick Coghlan gmail.com> writes:
>
> No, you misunderstand what I meant. Py_buffer doesn't need to be changed
> at all. The *issuing type* would define a new structure with the
> additional fields, such as:
With to the current buffer API, this is not possible. It's the caller who
allocates the Py
Alexander Belopolsky gmail.com> writes:
>
> I did not follow numpy development for the last year or more, so I
> won't qualify as "the numpy folks," but my understanding is that numpy
> does exactly what Nick recommended: the viewed object owns shape and
> strides just as it owns the data. The v
Le mardi 09 décembre 2008 à 22:33 +1000, Nick Coghlan a écrit :
> I have zero problem whatsoever if slice assignment TO a memoryview
> object is permitted only if the shape stays the same (i.e. I think that
> issue should be closed as "not a bug").
I'm not even talking about slice /assignment/ her
Antoine Pitrou pitrou.net> writes:
>
> > The first is that memoryview is treating the len field in the
> > Py_buffer struct as the number of objects in the view in a few places
> > instead of as the total number of bytes being exposed (it is actually
> > the
Nick Coghlan gmail.com> writes:
>
> For the slicing problem in particular, memoryview is currently trying to
> get away with only one Py_buffer object when it needs TWO.
Why should it need two? Why couldn't the embedded Py_buffer fullfill all the
needs of the memoryview object? If the memoryview
Greg Ewing canterbury.ac.nz> writes:
>
>1) The memoryview should *not* be holding onto a Py_buffer
> in between calls to its getitem and setitem methods. It
> should request one from the underlying object when needed
> and release it again as soon as possible.
If the memory
Nick Coghlan gmail.com> writes:
>
> I don't see anything wrong with the PEP 3118 protocol.
Apart from the fact that:
- it uses something (Py_buffer) which is not a PyObject and has totally
different allocation/lifetime semantics (which makes it non-trivial to adapt to
for anyone used to the rest
Greg Ewing canterbury.ac.nz> writes:
>
> This was a deliberate decision -- in fact I argued for it myself.
> The buffer interface is meant to be a minimal-overhead way for
> C code to get at the underlying data. Requiring allocation of
> a PyObject would be too expensive.
Tuples are used everywh
pobox.com> writes:
>
> The Python distribution comes with a Misc/gdbinit file (you can grab it from
> the Subversion source tree via the web as well) that defines a pystack
> command. It will work with core files as well as running processes and
> should give you a very good idea where your Pyth
pobox.com> writes:
>
> I understand. The guy has a problem today for which there is a solution
> that I posted. If he's "been meaning to look into the problem" and he's
> posting to python-dev I presume he knows at least a little about running gdb
> if he's operating in a Unix environment. The
Curt Hagenlocher hagenlocher.org> writes:
>
>
> On Thu, Dec 11, 2008 at 10:19 PM, Adam Olsen gmail.com> wrote:
>
>
> I doubt that UTF-16 is used very much (other than on windows).
>
> There's this other obscure platform called "Java"... ;)
Does it have a filesystem?
_
Hello,
Edd Barrett gmail.com> writes:
>
> I just had to move the "extern lstat..." outside the "ifndef
> HAVE_LSTAT" to get python 2.6.1 to build on OpenBSD 4.4-current/i386.
Could you please open an issue in http://bugs.python.org ? That way the problem
is less likely to be overlooked.
By the
Curt Hagenlocher hagenlocher.org> writes:
>
> No, but it also has to interact with filesystems of possibly invalid
> or indeterminate encodings. What does java.io do?
My point was that Python doesn't have to interact with the Java IO libraries,
while it has to interact with the Unix and Windows
Hello,
I remember there were some talks of reindenting the C code base (from tabs to
4-space indents) after py3k is released, but I can't find the discussion thread
again. Was a decision ever taken about it?
Regards
Antoine.
___
Python-Dev mailing l
Guido van Rossum python.org> writes:
>
> I think we should not do this. We should use 4 space indents for new
> files, but existing files should not be reindented.
Well, right now many files are indented with a mix of spaces and tabs, depending
on who did the edit and how their editor was config
Jeffrey Yasskin gmail.com> writes:
>
> I've never figured out how to configure emacs to deduce whether the
> current file uses spaces or tabs and has a 4 or 8 space indent.
Same question for Kate! Although I guess that if emacs isn't able to do it, Kate
won't do it either...
(Kate allows config
Martin v. Löwis v.loewis.de> writes:
>
> I guess it would be possible to write a Kate plugin that does that.
Or perhaps more simply, Kate allows modelines at the beginning and at the end of
source files. I don't know if it's ok to add these to the code base though.
___
Hello,
There are recurring complaints about the garbage collector degrading performance
when lots of objects are created in a row. In issue #4074, I've proposed a patch
which basically implements Martin's suggestion in
http://mail.python.org/pipermail/python-dev/2008-June/080579.html to base the
Christian Heimes cheimes.de> writes:
>
> Is it reasonable to implement multiple policies so the user can switch
> between them? Or is the new algorithm superior in all cases?
We could let the user configure the threshold between the old policy and the new
policy. Currently it is hard-wired to a
Antoine Pitrou pitrou.net> writes:
>
> We could let the user configure the threshold between the old policy and the
new
> policy. Currently it is hard-wired to a value of 1 (that is, 1
> long-lived objects tracked by the GC).
I've removed the threshold in the lates
Martin v. Löwis v.loewis.de> writes:
>
> So despite the organizational overhead, I'd appreciate if you could
> create separate patches, if not separate issues.
Ok, I'm gonna do that.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.or
> Well, ``python -h`` still lists it.
Precisely, it says:
-u : unbuffered binary stdout and stderr; also PYTHONUNBUFFERED=x
see man page for details on internal buffering relating to '-u'
Note the "binary". And indeed:
./python -u
Python 3.1a0 (py3k:67839M, Dec 18 2008, 17:56:54)
Nick Coghlan gmail.com> writes:
>
> There are some memoryview issues [1] I'd like to have fixed for 3.0.1 -
> the 29th would be a much easier date to hit. A quick review pass through
> the other 3.0 highs and criticals might also be worthwhile.
What about #1717 "Get rid of more refercenes to __c
Antoine Pitrou pitrou.net> writes:
>
> Note the "binary". And indeed:
[...]
And I realize I should have thought a bit before giving that "proof".
Sorry!
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
Steven D'Aprano pearwood.info> writes:
>
> In November 2007, a similar problem was reported on the comp.lang.python
> newsgroup. 370MB was large enough to demonstrate the problem. I don't
> know if a bug was ever reported.
Do you still reproduce it on trunk?
I've tried your scripts on my machi
Leif Walsh gmail.com> writes:
>
> It might be a semantic change that I'm looking for here, but it seems
> to me that if you turn off the garbage collector, you should be able
> to expect that either it also won't run on exit, or it should have a
> way of letting you tell it not to run on exit.
[
Steve Holden holdenweb.com> writes:
> I believe the OP engendered a certain amount of confusion by describing
> object deallocation as being performed by the garbage collector. So he
> perhaps didn't understand that even decref'ing all the objects only
> referenced by the dict will take a huge amo
Mike Coleman gmail.com> writes:
>
> Just to clarify, I didn't gc.disable() to address this problem, but
> rather because it destroys performance during the creation of the huge
> dict. I don't have a specific number, but I think disabling gc
> reduced construction from something like 70 minutes
Mike Coleman gmail.com> writes:
>
> The 45G was the VM size of the process (resident size was similar).
Can you reproduce it with a smaller working set? Something between 1 and 2GB,
possibly randomly-generated, and post both the generation script and the
problematic script on the bug tracker?
Barry Warsaw python.org> writes:
>
> Please make sure these issues are release blockers. Fixes before
> January 5th would be able to make it into 3.0.1.
Should http://bugs.python.org/issue4486 be a release blocker as well?
(I don't think so, but...)
Martin v. Löwis v.loewis.de> writes:
>
> It then occurred that there are only 64 different values for nfreepools,
> as ARENA_SIZE is 256kiB, and POOL_SIZE is 4kiB. So rather than keeping
> the list sorted, I now propose to maintain 64 lists, accessible in
> an array double-linked lists indexed by
> Now, we should find a way to benchmark this without having to steal Mike's
> machine and wait 30 minutes every time.
So, I seem to reproduce it. The following script takes about 15 seconds to
run and allocates a 2 GB dict which it deletes at the end (gc disabled of
course).
With 2.4, deleting t
pobox.com> writes:
> You could I suppose though that would just be adding another hack on top of
> existing questionable behavior.
Agreed. We should fix the original function so that it has the obvious, intented
effect. Leaving the buggy function in place and adding another function with the
prop
pobox.com> writes:
>
> If we add commonpath or commonpathprefix or pathprefix, or whatever, then
> find someplace to move the existing commonprefix function (maybe to the
> string module or as a class method of string objects?) then could we make a
> 2to3 fixer for this?
IMHO it's a bug, the py3
Nick Coghlan gmail.com> writes:
>
> The current behaviour is exactly what one would need to implement
> bash-style tab completion [1], so I don't get why anyone is calling it
> "useless" or "obviously broken".
Point taken.
Although the fact that it lives in os.path suggests that the function sh
Le dimanche 28 décembre 2008 à 16:26 +1000, Nick Coghlan a écrit :
> If we're going to end up with two functions anyway, why mess with the
> one which is already there and in use for real programs?
Well, agreed.
I was just hoping we could get away with "fixing" the existing function
and voilà :)
Hello,
> I'm currently studying all I can find on stackless python, PYPY and the
> concepts they've brought to Python, and so far I wonder : since
> stackless python claims to be 100% compatible with CPython's extensions,
> faster, and brings lots of fun stuffs (tasklets, coroutines and no C
Hi all,
Could we use the -M option (with a suitable value depending on the amount of
physical RAM) for regression tests on the buildbots? It would help avoid the
kind of situation described in http://bugs.python.org/issue3700
cheers
Antoine.
___
Pyth
Jesus Cea jcea.es> writes:
>
> Mike Coleman wrote:
> > I guess if ints are 12 bytes (per Beazley's book, but not sure if that
> > still holds), then that would correspond to a 1GB reduction.
>
> Python 2.6.1 (r261:67515, Dec 11 2008, 20:28:07)
> [GCC 4.2.3] on sunos5
> Type "help", "copyright",
pobox.com> writes:
>
> which leads me to believe that other people using the current function in
> the real world would be confused by your interpretation.
... and are vulnerable to security hazards.
___
Python-Dev mailing list
Python-Dev@python.org
Hello,
I would like to mention that I've written a patch which enables "threaded
interpretation" on the ceval loop with gcc (*). On my computer (an Athlon X2
3600+), it is good for a 15-20% speedup of the interpreter on pystone and
pybench. I also had the opportunity to test it on a Core2-derived
Antoine Pitrou pitrou.net> writes:
>
> I would like to mention that I've written a patch which enables "threaded
> interpretation"
... and I forgot to give the URL:
http://bugs.python.org/issue4753
Regards
Antoine.
Hi,
Stephen J. Turnbull xemacs.org> writes:
>
> There *is* a process problem, though I don't claim to have an idea how
> to solve it. Some developers (especially well-known is Martin van
> Loewis) are trying to address this with the "one committer's review
> for five reviews" offer, but maybe
David Cournapeau gmail.com> writes:
>
> It does not make integration easier, but it certainly makes patch
> management easier for the patch writer. There are other means to
> manage patch on top of svn, but I find git-svn extremely useful.
> Actually, I use git-svn on top of svn repositories for
Ulrich Eckhardt knuut.de> writes:
>
> saying "please merge r1234 from
> foo into trunk" is much easier than downloading and applying a patch, which
> doesn't even cover all possible changes that SVN does.
I don't know about others, but downloading and applying a patch doesn't
bother me (it's a
Ulrich Eckhardt knuut.de> writes:
>
> 1. I think that a patch can not e.g. capture a moved, renamed or deleted
> file.
> Further, it can not handle e.g. things like the executable bit or similar
> things that SVN otherwise does manage. That is what makes a patch only
> partially suitable.
Yo
Georg Brandl gmx.net> writes:
>
> It looks like it does, and that's a good thing (once in a while).
Hey, and we've even had a DVCS sub-thread in the process ;)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
Barry Warsaw python.org> writes:
>
> Although it doesn't help Victor specifically, anyone with svn commit
> privileges also has permission to push Bazaar (and I think Mercurial)
> branches back to code.python.org.
Actually the Mercurial repositories are read-only. We would need some
server-s
Hello,
it seems that both the following pages are identical, and are for
release30-maint:
http://www.python.org/dev/buildbot/3.0.stable/
http://www.python.org/dev/buildbot/3.x.stable/
Isn't the latter supposed to point to the py3k branch buildbots?
Regards
Antoine.
___
Barry Warsaw python.org> writes:
>
> Do any of the DVCS under consideration satisfy that requirement?
Out of curiosity, I apt-get'ed Mercurial on a stable Debian (0.9.1-1+etch1)
and I was able to clone the trunk mirror (*) fine. It just took a bit over two
minutes.
(*) http://code.python.org/hg
Martin v. Löwis v.loewis.de> writes:
> > As for Mercurial, I have been told their repository layout has not
> > changed since their first release and updates have been more about bug
> > fixes and speed improvements.
>
> Speed improvements we can ignore; for bug fixes, it would be good to
> know
Martin v. Löwis v.loewis.de> writes:
>
> Correct. To specify a different compiler, set the CC environment
> variable, and don't pass the --without-gcc flag.
Perhaps --without-gcc should be removed, if it's both useless and misleading?
(note: I don't have an interest in the matter)
___
Hello,
Amaury (mainly) and I are rewriting the IO stack in C, and there is a small
thing in PEP 3116 about the BufferedRandom object that I'd like to clarify:
« Q: Do we want to mandate in the specification that switching between reading
and writing on a read-write object implies a .flush()? Or
Hello,
Malte Helmert informatik.uni-freiburg.de> writes:
>
> are their any plans to organize another Python Bug Day in the near
> future? It's been a while since the last one (last May). I might be
> misremembering, but I think at one time there was even talk of having
> one bug day every month
Simon Cross gmail.com> writes:
> It'd also be nice if there could be some committers around on IRC to
> have fast interactions with or perhaps to coordinate things
I was going to suggest #python-dev but I see you're already there...
___
Python-Dev m
Guido van Rossum python.org> writes:
>
> However, the semantics of interleaving
> reads and writes, with and without seek calls in between, should be
> well-defined and correct/useful, so that it behaves the same
> regardless of the buffer size.
Yes, the goal is to have reasonably intuitive, and
Hello,
I've just noticed that in py3k, the decoding functions in the codecs module
accept str objects as well as bytes:
# import codecs
# c = codecs.getdecoder('utf8')
# c('aa')
('aa', 2)
# c('éé')
('éé', 4)
# c = codecs.getdecoder('latin1')
# c('aa')
('aa', 2)
# c('éé')
('éé', 4)
I
Guido van Rossum python.org> writes:
>
> Sounds like yet another remnant of the old philosophy, which indeed
> supported encode and decode operations on both string types.
How do we go for fixing it? Is it ok to raise a TypeError in 3.0.1?
___
Pyth
Hello,
In http://www.python.org/dev/buildbot/, there's a link suggesting to visit the
pybots Web site for more information. However, http://www.pybots.org/ just says
"Nothing here #".
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
M.-A. Lemburg egenix.com> writes:
>
> No, that's something I explicitly readded to Python 3k, since the
> codecs interface is independent of the input and output types (the
> codecs decide which combinations to support).
But why would the utf8 decoder accept unicode as input?
Brett Cannon python.org> writes:
>
> One, does anyone have issues if I check in importlib? We have
> typically said code has to have been selected as best-of-breed by the
> community first, so I realize I am asking for a waiver on this one.
Have you tried to assess its interaction with setuptool
Robert Schwebel pengutronix.de> writes:
>
> If cross compiling it must be possible to overwrite the so_ext from the
> outside.
Thanks for those patches, but please post them to the issue tracker instead
(http://bugs.python.org/). If each patch is for a distinct purpose, then open
separate issues
Hello,
Python currently has an API to deal with size_t-like numbers (Py_ssize_t,
PyNumber_AsSsize_t), but it doesn't have similar facilities for off_t.
Is it ok to add the following:
* a Py_off_t type which is typedef'd to either Py_LONG_LONG (Windows) or off_t
(others)
* three C API functions:
Martin v. Löwis v.loewis.de> writes:
>
> -1. How many functions actually require that type?
Functions in the IO lib. I can't tell you how many, let's say a dozen.
> > (the motivation is systems where Py_ssize_t is 32-bits wide, but large file
> > support makes off_t 64 bits wide)
>
> For argum
Nick Coghlan gmail.com> writes:
>
> I'd say start with the private version in IO lib, and then if there is
> demand consider moving it to abstract.h (but, like Martin, I don't
> expect such demand to ever develop).
Ok, I'm gonna do this.
Thanks
Antoine.
__
Kristján Valur Jónsson ccpgames.com> writes:
>
> On Vista, it will return an AF_INET6 entry before the
> AF_INET one and try connection to that. This connect() attemt fails after
> approximately one second, after which we proceed to do an immediately
> successful connect() call to the AF_INET ad
Kristján Valur Jónsson ccpgames.com> writes:
> Seem bogus.
> For ftruncate, an invalid filedescriptor really should return OSError, and
close(10) should raise an
> OSError as well.
It seems wrong to assume that 10 is an invalid file descriptor at the time of
running the test.
IMO you should first
Mark Dickinson gmail.com> writes:
>
> Benjamin wondered aloud about deprecating PyNumber_Long
> in the issue 4910 discussion; I suggested deprecating
> PyNumber_Int instead, but on reflection I think Benjamin's right:
> it seems neater to keep the PyNumber_Int <-> int() <-> nb_int
> naming conne
Luke Kenneth Casson Leighton lkcl.net> writes:
> running under wine, ftell() has an off-by-one bug, where the file
> position accidentally doesn't include the fact that the CR of the CRLF
> has been skipped. but, now with the fgets() bug fixed, the regression
> tests pass, but there's still the o
Dear python-dev,
The Python implementation of IOBase, the base class for everything IO, has the
(strange) idea to define a __del__ method. It is probably meant to avoid code
duplication, so that users subclassing IOBase automatically get the
close-on-destruct behaviour.
(there is an even stranger
Alexey G. Shpagin udmvt.ru> writes:
>
> Example will look like
> g = (n for n in range(100) if n*n < 50 or else_break())
Please don't suggest any hack involving raising StopIteration as part of a
conditional statement in a generator expression. It might work today, but it
might as well break to
Brett Cannon python.org> writes:
>
> I have now converted PEP 374
> (http://www.python.org/dev/peps/pep-0374/) from Google Docs to reST
> and checked it in. I am not going to paste it into an email as it is
> nearly 1500 lines in reST form.
It seems the ">>" token is mangled into a French closin
Giovanni Bajo develer.com> writes:
>
> The fact that file objects are collected and closed immediately in all
> reasonable use cases (and even in case of exceptions, that you mention,
> things get even better with the new semantic of the except clause)
The new except clause removes any external
Guido van Rossum python.org> writes:
>
> And, by the way, "for line in open(filename): ..." will continue to
> work. It may just not close the file right away. This is a forgivable
> sin in a small program that opens a few files only. It only becomes a
> program when this is itself inside a loop
Luke Kenneth Casson Leighton lkcl.net> writes:
>
> that means that the Py_None macro must call the "getter" function.
Given the negative performance implications that it would have, chances are it
is out of question.
Also, while not a Windows expert *at all*, I'd question your interpretation of
Barry Warsaw python.org> writes:
> >>
> >> Besides, certain developments like support for the svn wire protocol
> >> in bzr would make the WFC (we fear change :) argument moot.
> >
> > This is an argument *against* the usefulness of switching!
>
> Why?
>
> This simply allows those who are happy
Martin v. Löwis v.loewis.de> writes:
> In
> essence, committers wanting to use a DVCS can do so today, by acting
> as if they were non-committers, and only using svn for actual changes
> to the master repository.
Indeed. It is how I work.
Regards
Antoine.
_
Hello python-dev,
r68924 in py3k introduced a new configure option named --with-computed-gotos. It
would be nice if one of the buildbots could exercise this option, so that the
code doesn't rot (the buildbot has to use gcc). Whom should I ask for this?
Speaking of which, there are only five buil
(Apologies for the incomplete title! I sometimes eat my words...)
Antoine Pitrou pitrou.net> writes:
>
> Hello python-dev,
>
[snip]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Martin v. Löwis v.loewis.de> writes:
>
> Me. Does it have to be a configure option? It is difficult to invoke
> different commands in different branches; better if the configures in
> all branches get the same options.
Well, after a quick test, it seems that configure doesn't complain if you pas
Hello Kevin,
> As an interested observer, but not yet user of the 3.x series, I was wondering
about progress on restoring io performance and what release those improvements
were slated for.
There is an SVN branch with a complete rewrite (in C) of the IO stack. You can
find it in branches/io-c. A
Benjamin Peterson python.org> writes:
>
> At the moment, there are 4 release blockers for 3.0.1. I'd like to see
> 3.0.1 released soon (within the next month.) It would fix the hugest
> mistakes in the initial release most of which have been done committed
> since December. I'm sure it would be a
Raymond Hettinger rcn.com> writes:
>
> What is involved in finishing io-in-c?
Off the top of my head:
- fix the _ssl bug which prevents some tests from passing (issue #4967)
- clean up io.py (and decide what to do with the remaining Python code:
basically, the parts of StringIO which are implem
Martin v. Löwis v.loewis.de> writes:
>
> > The IO-in-C branch cannot be reasonably pulled in release30-maint, but it
will
> > be ready for 3.1.
>
> Even if 3.1 is released in February?
No, unless we take some risks and rush it in.
(technically, it seems to work, but it's such a critical piece o
Daniel Stutzbach stutzbachenterprises.com> writes:
>
> Would it be much trouble to also compare performance with Python 2.6?
Here are the results on trunk. Keep in mind Text IO, while it's still `open("r",
filename)`, does not mean the same thing.
=== 2.7 I/O (trunk) ===
** Binary input **
Raymond Hettinger rcn.com> writes:
>
> Also, 3.0 is a special case because it is IMO a broken release.
> AFAICT, it is not in any distro yet.
I have access to an Ubuntu 8.10 box and:
$ apt-cache search python3.0
idle-python3.0 - An IDE for Python (v3.0) using Tkinter
libpython3.0 - Shared Pytho
Daniel Stutzbach stutzbachenterprises.com> writes:
>
> Thanks, Antoine! To make comparison easier, I put together the results into a
Google
Spreadsheet:http://spreadsheets.google.com/pub?key=pbqSxQEo4UXwPlifXmvPHGQ
Thanks, that's much more readable indeed.
> That's because in Python 3, the Te
Daniel Stutzbach stutzbachenterprises.com> writes:
>
> What kind of input are you using for the Text tests? I'm kind of surprised
that the conversion to Unicode results in such a dramatic slowdown, if you're
feeding it plain text (characters 0x00 through 0x7f).
It's some arbitrary text composed
Daniel Stutzbach stutzbachenterprises.com> writes:
> For the "10MB whole contents at once" test, we then have:
> (assuming the code does no pipelining of disk I/O with decoding)
>
> 10MB / 980MB/s to read from disk = 10 ms
> 10MB / 250MB/s to decode to utf8 = 40 ms
> 10MB / (10ms + 40ms) = 200 MB
Hello,
Raymond Hettinger rcn.com> writes:
>
> >MB/S MB/SMB/S
> >in C in py3k in 2.7 C/3k 2.7/3k
> > ** Text append **
> > 10M write 1e6 units at a time261.00 218.000 1540.000 1.20 7.06
> > 20K w
Paul Moore gmail.com> writes:
>
> It would be helpful to limit this cost as much as possible - maybe
> that's simply ensuring that the default encoding for open is (in the
> majority of cases) a highly-optimised one whose costs *don't* dominate
> in the way you describe
As I pointed out, utf-8,
Victor Stinner haypocalc.com> writes:
>
> Le Wednesday 28 January 2009 11:55:16 Antoine Pitrou, vous avez écrit :
> > 2.x has no encoding costs, which explains why it's so much faster.
>
> Why not testing io.open() or codecs.open() which create unicode strings
3901 - 4000 of 4909 matches
Mail list logo
