On May 2, 2012 6:00 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 02 May 2012 01:43:32 -0700
Larry Hastings la...@hastings.org wrote:
I realize we can't jump to C99 because of A Certain Compiler. (Its name
rhymes with Bike Row Soft Frizz You All See Muss Muss.) But even that
Cheers
On Apr 21, 2012 10:25 AM, R. David Murray rdmur...@bitdance.com wrote:
On Sat, 21 Apr 2012 08:54:56 +0800, Matt Joiner anacro...@gmail.com
wrote:
I'm getting one of these every couple of days. What's the deal?
On Apr 21, 2012 1:03 AM, Python tracker
roundup-ad
I'm getting one of these every couple of days. What's the deal?
On Apr 21, 2012 1:03 AM, Python tracker
roundup-ad...@psf.upfronthosting.co.za wrote:
An unexpected error occurred during the processing
of your message. The tracker administrator is being
notified.
Return-Path:
Personally I find the unholy product of C and Python that is Cython to be
more complex than the sum of the complexities of its parts. Is it really
wise to be learning Cython without already knowing C, Python, and the
CPython object model?
While code generation alleviates the burden of tedious
This is becoming the Manhattan Project of bike sheds.
___
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
+1! Thanks for pushing this.
On Apr 15, 2012 4:04 AM, Brett Cannon br...@python.org wrote:
To start off, what I am about to propose was brought up at the PyCon
language summit and the whole room agreed with what I want to do here, so I
honestly don't expect much of an argument (famous last
On Apr 10, 2012 2:36 AM, Terry Reedy tjre...@udel.edu wrote:
On 4/9/2012 9:13 AM, r.david.murray wrote:
http://hg.python.org/cpython/rev/eff551437abd
changeset: 76176:eff551437abd
user:R David Murrayrdmur...@bitdance.com
date:Mon Apr 09 08:55:42 2012 -0400
summary:
The discussion has completed degenerated. There are several different
clocks here, and several different agendas.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Finally! We've come full circle.
+1 for monotonic as just described by Victor.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Lock it in before the paint dries.
On Apr 4, 2012 10:05 AM, Matt Joiner anacro...@gmail.com wrote:
Finally! We've come full circle.
+1 for monotonic as just described by Victor.
___
Python-Dev mailing list
Python-Dev@python.org
http
time.monotonic(): The uneventful and colorless function.
On Mar 28, 2012 9:30 PM, Larry Hastings la...@hastings.org wrote:
On 03/28/2012 01:56 PM, R. David Murray wrote:
On Wed, 28 Mar 2012 23:05:59 +1100, Steven D'Apranost...@pearwood.info
wrote:
+1 on Nick's suggestion of try_monotonic.
time.timeout_clock?
Everyone knows what that will be for and we won't have to make silly
theoretical claims about its properties and expected uses.
If no one else looks before I next get to a PC I'll dig up the clock/timing
source used for select and friends, and find any corresponding syscall
I renamed time.steady() to time.try_monotonic() in the PEP. It's a
temporary name until we decide what to do with this function.
How about get rid of it?
Also monotonic should either not exist if it's not available, or always
guarantee a (artificially) monotonic value. Finding out that
On Mar 28, 2012 8:38 AM, Victor Stinner victor.stin...@gmail.com wrote:
Scott wrote:
The Boost implementation can be summarized as:
system_clock:
mac = gettimeofday
posix = clock_gettime(CLOCK_REALTIME)
win = GetSystemTimeAsFileTime
steady_clock:
mac = mach_absolute_time
posix
FWIW it doesn't hurt to err on the side of what worked. i have generally
have issues with low contrast, the current stable design is very good with
this.
i've just built the docs from tip, and the nav bar issue is fixed, nicely
done
i also don't see any reason to backport theme changes, +0
the text in the nav bar is too small, particularly in the search box.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Inside time.steady, there are two different clocks trying to get out.
I think this steady business should be removed sooner rather than later.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
So does anyone care to dig into the libstd++/boost/windoze implementation
to see how they each did steady_clock?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Cheers, that clears things 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
Is nice yes?! When I small the nav bar, then embiggen it again, the text
centers vertically. It's in the wrong place. The new theme is very minimal,
perhaps a new color should be chosen. We've done green, what about orange,
brown or blue?
___
Python-Dev
Not sure if you addressed this in your answers to other comments...
Scroll down the page. Minimize the nav bar on the left. Bring it back
out again. Now the text in the nav bar permanently starts at an offset
from the top of the page.
On Sun, Mar 25, 2012 at 7:44 PM, Matt Joiner anacro
Yes, call it what it is. monotonic or monotonic_time, because that's why
I'm using it. No flags.
I've followed this thread throughout, and I'm still not sure if steady
gives the real guarantees it claims. It's trying to be too much. Existing
bugs complain about backward jumps and demand a clock
The 24 core machine at my last workplace could configure and make the tip
in 45 seconds from a clean checkout.
Lots of cores? :)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Turn your monitor portrait or make the window smaller :)
___
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
I believe we should make a monotonic_time method that assures monotonicity
and be done with it. Forward steadiness can not be guaranteed. No
parameters.
On Mar 20, 2012 2:56 PM, Steven Dapos;Aprano st...@pearwood.info wrote:
On Mon, Mar 19, 2012 at 01:35:49PM +0100, Victor Stinner wrote:
Said
On Mar 15, 2012 4:23 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 15 March 2012 01:58, Matt Joiner anacro...@gmail.com wrote:
Victor, I think that steady can always be monotonic, there are time
sources
enough to ensure this on the platforms I am aware of. Strict in this
sense
refers
+1. I now prefer time.monotonic(), no flags. It attempts to be as high
precision as possible and guarantees never to jump backwards. Russell's
comment is right, the only steady sources are from hardware, and these are
too equipment and operating system specific. (For this call anyway).
On Mar 16,
Windows also has this albeit course grained and also 32 bit. I don't think
ticks reflects the reason why using the timer is desirable.
monotonic_time seems reasonable, there's no reason to persist short names
when users can import it how they like.
On Mar 16, 2012 7:20 AM, Steven Dapos;Aprano
I have some observations regarding this:
Victor's existing time.monotonic and time.wallclock make use of
QueryPerformanceCounter, and CLOCK_MONOTONIC_RAW as possible. Both of
these are hardware-based counters, their monotonicity is just a
convenient property of the timer sources. Furthermore,
Can you give a pointer to these one-liners?
Once a patch gets a month old or older, it tends to disappear from
everyone's radar unless you somehow ping on the tracker, or post a
message to the mailing-list.
All of these can be verified with a few minutes of checking the
described code paths.
On Thu, Mar 15, 2012 at 12:22 AM, Guido van Rossum gu...@python.org wrote:
I have a totally different observation. Presumably the primary use
case for these timers is to measure real time intervals for the
purpose of profiling various operations. For this purpose we want them
to be as steady
FWIW the name is quite important, because these kind of timings are
quite important so I think it's worth the effort.
- By default, it should fall back to time.time if a better source is
not available, but there should be a flag that can disable this
fallback for users who really *need* a
I also can live with steady, with strict for the flag.
___
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
Victor, I think that steady can always be monotonic, there are time sources
enough to ensure this on the platforms I am aware of. Strict in this sense
refers to not being adjusted forward, i.e. CLOCK_MONOTONIC vs
CLOCK_MONOTONIC_RAW.
Non monotonicity of this call should be considered a bug.
On Mar 14, 2012 5:27 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 13 Mar 2012 14:16:40 -0700
Guido van Rossum gu...@python.org wrote:
On Tue, Mar 13, 2012 at 12:49 PM, Terry Reedy tjre...@udel.edu wrote:
Authors of separately maintained packages are, from our viewpoint, as
Thanks for the suggestions.
On Mar 14, 2012 12:03 PM, Eli Bendersky eli...@gmail.com wrote:
Rather than indicating apathy on the party of third party developers,
this
might be a sign that core Python is unapproachable or not worth the
effort.
For instance I have several one line patches
Definitely think some library vetting needs to occur. Superior alternatives
do exist and are difficult to find and choose from. Stuff like LXML,
Requests, Tornado are clear winners.
The more of this done externally (ie PyPI the better). I still think a set
of requirements for official approval
Big +1
On Feb 26, 2012 4:41 PM, Eli Bendersky eli...@gmail.com wrote:
On Sat, Feb 25, 2012 at 12:20, Martin v. Löwis mar...@v.loewis.dewrote:
I find that strange, especially for an expert Python dev. I, a newbie,
find it far friendlier (and easier for a new programmer to grasp).
Maybe
+1 for won't fix.
On Feb 26, 2012 9:46 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 26 Feb 2012 14:27:21 +0100
Stefan Krah ste...@bytereef.org wrote:
The underlying problems with memoryview were intricate and required
a long discussion (issue #10181) that led to a complete
Chrome does something similar. All digits keep rising in that scheme.
However in your examples you can't identify whether bug fixes are to stdlib
or interpreter?
On Feb 26, 2012 10:07 AM, Terry Reedy tjre...@udel.edu wrote:
We have two similar proposals, PEPs 407 and 413, to speed up the release
I think every minor release should be fully supported. The current rate of
change is very high and there's a huge burden on implementers and
production users to keep up, so much so that upgrading is undesirable
except for serious enthusiasts.
Include just the basics and CPython specific modules
addressing this. I would suggest Haskell, node.js and golang as
examples of how stdlibs are minimal enough to define basic idiomatic
interfaces but allow and encourage extension.
On Feb 25, 2012 10:53 AM, Brett Cannon br...@python.org wrote:
On Fri, Feb 24, 2012 at 21:08, Matt Joiner anacro
On Mon, Feb 20, 2012 at 11:27 PM, Antoine Pitrou solip...@pitrou.net wrote:
IMHO, nesting without a good, consistent, systematic categorization
leads to very unpleasant results (e.g. from urllib.request import
urlopen).
Historically, our stdlib has been flat and I think it should stay so,
+1 for using symlinks where possible. In deploying Python to different
operating systems and filesystems I've often had to run a script to fix
the hardlinking done by make install because the deployment mechanism or
system couldn't be trusted to do the right thing with respect to minimising
+1
On Feb 4, 2012 8:37 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 4 February 2012 11:25, Steven D'Aprano st...@pearwood.info wrote:
It strikes me that it would be helpful sometimes to programmatically
recognise preview modules in the std lib. Could we have a
recommendation
in PEP 8 that
Woohoo! :)
___
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
raise from None seems pretty in band. A NoException class could have many
other uses and leaves no confusion about intent.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Nick mentioned using a single type and converting upon return, I'm starting
to like that more. A limited set of time formats is mostly arbitrary, and
there will always be a performance hit deciding which type to return.
The goal here is to allow high precision timings with minimal cost. A
Analysis paralysis commence. +1 for separate module using decimal.
On Feb 1, 2012 1:44 PM, PJ Eby p...@telecommunity.com wrote:
On Tue, Jan 31, 2012 at 7:35 PM, Nick Coghlan ncogh...@gmail.com wrote:
Such a protocol can easily be extended to any other type - the time
module could provide
It's also potentially lossy if you incremented and decremented until
integer precision is lost. My vote is for an int type check. No casting.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Sounds good, but I also prefer Alexander's method. The type information is
already encoded in the class object. This way you don't need to maintain a
mapping of strings to classes, and other functions/third party can join in
the fun without needing access to the latest canonical mapping. Lastly
I think an advocacy of 3rd party modules would start with modules such as
ipaddr, requests, regex. Linking directly to them from the python core
documentation, while requesting they hold a successful moratorium in order
to be included in a later standard module release.
On Jan 30, 2012 10:47 AM,
+1. I'd much rather just use the module from PyPI.
It would be good to have a practical guide on how to manage the
transition from third-party to core library module though. A PEP with
a list of modules earmarked for upcoming inclusion in the standard
library (and which Python version
__preview__ would fall into this category as well). And yet I have
essentially no means of gaining access to any 3rd party modules,
whether they are packaged by the distro or obtained from PyPI. (And
build your own isn't an option in many cases, if only because a C
compiler may well not be
+0. I think the idea is right, and will help to get good quality
modules in at a faster rate. However it is compensating for a lack of
interface and packaging standardization in the 3rd party module world.
___
Python-Dev mailing list
A more normal incantation, as is often the way for packages that became
parts of the standard library after first being a third party library
(sometimes under a different name, e.g. simplejson - json):
try:
from __preview__ import thing
except ImportError:
import thing
So no need
On Fri, Jan 27, 2012 at 12:26 PM, Alex alex.gay...@gmail.com wrote:
I think a significantly healthier process (in terms of maximizing feedback and
getting something into it's best shape) is to let a project evolve naturally
on
PyPi and in the ecosystem, give feedback to it from an inclusion
FWIW I'm now -1 for this idea. Stronger integration with PyPI and
packaging systems is much preferable. Python core public releases are
no place for testing.
On Sat, Jan 28, 2012 at 2:42 AM, Matt Joiner anacro...@gmail.com wrote:
On Fri, Jan 27, 2012 at 12:26 PM, Alex alex.gay...@gmail.com wrote
After much consideration, and playing with PEP380, I've changed my
stance on this. Full blown coroutines are the proper way forward.
greenlet doesn't cut it because the Python interpreter isn't aware of
the context switches. Profiling, debugging and tracebacks are
completely broken by this.
My concern is that you will end up with vastly more 'yield from's
than places that require locks, so most of them are just noise.
If you bite your nails over whether a lock is needed every time
you see one, they will cause you a lot more anxiety than they
alleviate.
Not necessarily. The
On Fri, Jan 20, 2012 at 8:41 AM, Greg greg.ew...@canterbury.ac.nz wrote:
Glyph wrote:
[Guido] mentions the point that coroutines that can implicitly switch out
from under you have the same non-deterministic property as threads: you
don't know where you're going to need a lock or lock-like
On Wed, Jan 18, 2012 at 6:55 PM, Georg Brandl g.bra...@gmx.net wrote:
The main reason is changes in the library. We have been getting complaints
about the standard library bitrotting for years now, and one of the main
reasons it's so hard to a) get decent code into the stdlib and b) keep it
PEP380 and Mark's coroutines could coexist, so I really don't it's
too late matters. Furthermore, PEP380 has utility in its own right
without considering its use for explicit coroutines.
I would like to see these coroutines considered, but as someone else
mentioned, coroutines via PEP380 enhanced
If minor/feature releases are introducing breaking changes perhaps it's
time to adopt accelerated major versioning schedule. For instance there are
breaking ABI changes between 3.0/3.1, and 3.2, and while acceptable for the
early adoption state of Python 3, such changes should normally be reserved
Just to clarify, this differs in functionality from enhanced generators by
allowing you to yield from an arbitrary call depth rather than having to
yield from through a chain of calling generators? Furthermore there's no
syntactical change except to the bottommost frame doing a co_yield? Does
this
Great work Nick, I've been looking forward to this one. Thanks all for
putting the effort in.
On Fri, Jan 13, 2012 at 11:14 PM, Nick Coghlan ncogh...@gmail.com wrote:
I marked PEP 380 as Final this evening, after pushing the tested and
documented implementation to hg.python.org:
On Thu, Jan 12, 2012 at 11:01 AM, Mike Meyer m...@mired.org wrote:
On Wed, 4 Jan 2012 00:07:27 -0500
PJ Eby p...@telecommunity.com wrote:
On Tue, Jan 3, 2012 at 7:40 PM, Mike Meyer m...@mired.org wrote:
A suite is marked
as a `transaction`, and then when an unlocked object is modified,
Perhaps the python-dev mailing list should be renamed to python-core.
On Tue, Jan 10, 2012 at 7:35 PM, Stefan Behnel stefan...@behnel.de wrote:
Hi,
sorry for hooking into this off-topic thread.
Amaury Forgeot d'Arc, 09.01.2012 19:09:
2012/1/9 paspa...@noos.fr
I am trying to send a tuple to
http://semver.org/
This has made sense since Gentoo days.
On Tue, Jan 10, 2012 at 11:57 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 10 Jan 2012 08:49:04 +
Rob Cliffe rob.cli...@btinternet.com wrote:
But minor version and major version are readily understandable to
the general
I suspect it actually would fix the confusion. dev usually means
development, not core implementation development. People float past
looking for dev help... python-dev. Python-list is a bit generic.
On Tue, Jan 10, 2012 at 11:17 PM, Stefan Behnel stefan...@behnel.de wrote:
Matt Joiner
Nick did you mean to say wrap python code around a reentrant lock to
create a non-reentrant lock? Isn't that what PyRLock is doing?
FWIW having now read issues 13697 and 13550, I'm +1 for dropping Python
RLock, and all the logging machinery in threading.
2012/1/8 Nick Coghlan ncogh...@gmail.com
_PyRLock is not used directly. Instead, no _CRLock is provided, so the
threading.RLock function calls _PyRLock.
It's done this way because green threading libraries may only provide a
greened lock. _CRLock in these contexts would not work: It would block the
entire native thread.
I suspect that
I'm pretty sure the Python version of RLock is in use in several
alternative implementations that provide an alternative _thread.lock. I
think gevent would fall into this camp, as well as a personal project of
mine in a similar vein that operates on python3.
2012/1/6 Charles-François Natali
FWIW I'm against forcing braces to be used. Readability is the highest
concern, and this should be at the discretion of the contributor. A
code formatting tool, or compiler extension is the only proper handle
this, and neither are in use or available.
On Tue, Jan 3, 2012 at 7:44 PM, Martin v.
I'm paid to write Python3. I've also been writing Python3 for hobby
projects since mid 2010. I'm on the verge of going back to 2.7 due to
compatibility issues :(
On Thu, Dec 22, 2011 at 1:45 PM, Mike Meyer m...@mired.org wrote:
On Thu, 22 Dec 2011 01:49:37 +
Michael Foord
ಠ_ಠ
On Sat, Dec 17, 2011 at 8:55 PM, Michael Mueller
mmuel...@vigilantsw.com wrote:
Hi Guys,
We've been analyzing CPython with our static analysis tool (Sentry)
and a NULL pointer dereference popped up the other day, in
Objects/descrobject.c:
if (descr != NULL) {
+1
On Sat, Dec 10, 2011 at 2:09 AM, Dirkjan Ochtman dirk...@ochtman.nl wrote:
On Fri, Dec 9, 2011 at 09:02, Stefan Behnel stefan...@behnel.de wrote:
a) The stdlib documentation should help users to choose the right tool right
from the start.
b) cElementTree should finally loose it's special
If braces were introduced I would switch to Haskell, I can't stand the
noise. If you want to see a language that allows both whitespace, semi
colons and braces take a look at it. Nails it.
On Dec 10, 2011 9:31 AM, Cedric Sodhi man...@gmx.net wrote:
On Fri, Dec 09, 2011 at 02:21:42PM -0800, Guido
I second this. The doco is very bad.
On Dec 10, 2011 6:34 AM, Bill Janssen jans...@parc.com wrote:
Xavier Morel python-...@masklinn.net wrote:
On 2011-12-09, at 19:15 , Bill Janssen wrote:
I use ElementTree for parsing valid XML, but minidom for producing it.
Could you expand on your
, Matt Joiner wrote:
If braces were introduced I would switch to Haskell, I can't stand the
noise. If you want to see a language that allows both whitespace, semi
colons and braces take a look at it. Nails it.
On Dec 10, 2011 9:31 AM, Cedric Sodhi [1]man...@gmx.net wrote
Nobody is using 3 yet ;)
Sure, I use it for some personal projects, and other people pretend to
support it. Not really.
The worst of the pain in porting to Python 3000 has yet to even begin!
On Thu, Dec 8, 2011 at 6:33 PM, Nick Coghlan ncogh...@gmail.com wrote:
Such code still won't work on
This is very interesting, cheers for the link.
On Tue, Dec 6, 2011 at 8:55 PM, Armin Rigo ar...@tunes.org wrote:
Hi,
Actually, not even one month ago, Intel announced that its processors
will offer Hardware Transactional Memory in 2013:
...@tunes.org wrote:
Hi,
On Thu, Dec 1, 2011 at 07:06, Matt Joiner anacro...@gmail.com wrote:
I saw this, I believe it just exposes an STM primitive to user code.
It doesn't make use of STM for Python internals.
That's correct.
Explicit STM doesn't seem particularly useful for a language
Given GCC's announcement that Intel's STM will be an extension for C
and C++ in GCC 4.7, what does this mean for Python, and the GIL?
I've seen efforts made to make STM available as a context, and for use
in user code. I've also read about the old attempts way back that
attempted to use finer
I did see this, I'm not convinced it's only relevant to PyPy.
On Thu, Dec 1, 2011 at 2:25 AM, Benjamin Peterson benja...@python.org wrote:
2011/11/30 Matt Joiner anacro...@gmail.com:
Given GCC's announcement that Intel's STM will be an extension for C
and C++ in GCC 4.7, what does this mean
I saw this, I believe it just exposes an STM primitive to user code.
It doesn't make use of STM for Python internals.
Explicit STM doesn't seem particularly useful for a language that
doesn't expose raw memory in its normal usage.
On Thu, Dec 1, 2011 at 4:41 PM, Nick Coghlan ncogh...@gmail.com
I like this article on it:
http://semver.org/
The following snippets being relevant here:
Minor version Y (x.Y.z | x 0) MUST be incremented if new, backwards
compatible functionality is introduced to the public API. It MUST be
incremented if any public API functionality is marked as
Congrats, this is an excellent feature.
On Wed, Nov 30, 2011 at 10:34 AM, Amaury Forgeot d'Arc
amaur...@gmail.com wrote:
2011/11/29 Nadeem Vawda nadeem.va...@gmail.com
I'm pleased to announce that as of changeset 74d182cf0187, the
standard library now includes support for the LZMA compression
On Mon, Nov 28, 2011 at 11:14 PM, Steven D'Aprano st...@pearwood.info wrote:
Xavier Morel wrote:
Not being too eager to kill APIs is good, but giving rise to this kind of
living-dead APIs is no better in my opinion, even more so since Python has
lost one of the few tools it had to manage them
On Fri, Nov 25, 2011 at 5:41 PM, Eli Bendersky eli...@gmail.com wrote:
Eli, the use pattern I was referring to is when you read in chunks,
and and append to a running buffer. Presumably if you know in advance
the size of the data, you can readinto directly to a region of a
bytearray. There by
You can see in the tests on the largest buffer size tested, 8192, that
the naive read actually outperforms readinto(). It's possibly by
extrapolating into significantly larger buffer sizes that readinto()
gets left behind. It's also reasonable to assume that this wasn't
tested thoroughly.
On Fri,
On Fri, Nov 25, 2011 at 10:04 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 25 Nov 2011 20:34:21 +1100
Matt Joiner anacro...@gmail.com wrote:
It's Python 3.2. I tried it for larger files and got some interesting
results.
readinto() for 10MB files, reading 10MB all at once
I was under the impression this is already in 3.3?
On Nov 25, 2011 10:58 PM, Eli Bendersky eli...@gmail.com wrote:
However, the original question remains - on the 100MB file also,
although
in 2.7 readinto is 35% faster than readandcopy(), on 3.2 it's about the
same speed (even a few %
What if you broke up the read and built the final string object up. I
always assumed this is where the real gain was with read_into.
On Nov 25, 2011 5:55 AM, Eli Bendersky eli...@gmail.com wrote:
On Thu, Nov 24, 2011 at 20:29, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 24 Nov 2011
Eli,
Example coming shortly, the differences are quite significant.
On Fri, Nov 25, 2011 at 9:41 AM, Eli Bendersky eli...@gmail.com wrote:
On Fri, Nov 25, 2011 at 00:02, Matt Joiner anacro...@gmail.com wrote:
What if you broke up the read and built the final string object up. I
always
guilty of this? Gmail
defaults to putting my response above the previous email.
On Fri, Nov 25, 2011 at 11:49 AM, Matt Joiner anacro...@gmail.com wrote:
Eli,
Example coming shortly, the differences are quite significant.
On Fri, Nov 25, 2011 at 9:41 AM, Eli Bendersky eli...@gmail.com wrote
On Fri, Nov 25, 2011 at 12:07 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 25 Nov 2011 12:02:17 +1100
Matt Joiner anacro...@gmail.com wrote:
It's my impression that the readinto method does not fully support the
buffer interface I was expecting. I've never had cause to use it until
97 matches
Mail list logo
