On May 2, 2012 6:00 PM, "Antoine Pitrou" wrote:
>
> On Wed, 02 May 2012 01:43:32 -0700
> Larry Hastings 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
> > compiler added this extens
Cheers
On Apr 21, 2012 10:25 AM, "R. David Murray" wrote:
>
> On Sat, 21 Apr 2012 08:54:56 +0800, Matt Joiner
> wrote:
> > I'm getting one of these every couple of days. What's the deal?
> > On Apr 21, 2012 1:03 AM, "Python tracker" <
> &
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:
> X-
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 lang
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" 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 words).
>
> In
On Apr 10, 2012 2:36 AM, "Terry Reedy" 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 Murray
>> date:Mon Apr 09 08:55:42 2012 -0400
>> summary:
>> #14533: if a test has
Lock it in before the paint dries.
On Apr 4, 2012 10:05 AM, "Matt Joiner" wrote:
> Finally! We've come full circle.
>
> +1 for monotonic as just described by Victor.
>
___
Python-Dev mailing list
Python-Dev@python.org
htt
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:
http://mail.python.org/mailman/options/python-dev/archive%40
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:
http://mail.python.org/mai
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 th
time.monotonic(): The uneventful and colorless function.
On Mar 28, 2012 9:30 PM, "Larry Hastings" wrote:
> On 03/28/2012 01:56 PM, R. David Murray wrote:
>
>> On Wed, 28 Mar 2012 23:05:59 +1100, Steven D'Aprano
>> wrote:
>>
>>> +1 on Nick's suggestion of try_monotonic. It is clear and obvious a
On Mar 28, 2012 8:38 AM, "Victor Stinner" 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 = clo
> 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 someth
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
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:
http://mail.python.org/mail
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
Unsubscrib
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:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archi
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
__
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 wrote:
>
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 m
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:
http://mai
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 D'Aprano" wrote:
> On Mon, Mar 19, 2012 at 01:35:49PM +0100, Victor Stinner wrote:
>
> > Said differently: time
Steven D'Aprano" wrote:
> Terry Reedy wrote:
>
>> On 3/15/2012 5:27 PM, Alexander Belopolsky wrote:
>>
>>> On Thu, Mar 15, 2012 at 3:55 PM, Matt Joiner
>>> wrote:
>>>
>>>> +1. I now prefer time.monotonic(), no flags.
>>&
+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, 2
On Mar 15, 2012 4:23 PM, "Paul Moore" wrote:
>
> On 15 March 2012 01:58, Matt Joiner 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
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. Strict
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
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
On Thu, Mar 15, 2012 at 12:22 AM, Guido van Rossum 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" as possible:
> 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 pa
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, time
Thanks for the suggestions.
On Mar 14, 2012 12:03 PM, "Eli Bendersky" 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 lang
On Mar 14, 2012 5:27 AM, "Antoine Pitrou" wrote:
>
> On Tue, 13 Mar 2012 14:16:40 -0700
> Guido van Rossum wrote:
>
> > On Tue, Mar 13, 2012 at 12:49 PM, Terry Reedy wrote:
> > > Authors of separately maintained packages are, from our viewpoint, as
> > > eligible to help with tracker issues as a
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" w
+1 for won't fix.
On Feb 26, 2012 9:46 PM, "Antoine Pitrou" wrote:
> On Sun, 26 Feb 2012 14:27:21 +0100
> Stefan Krah wrote:
> >
> > The underlying problems with memoryview were intricate and required
> > a long discussion (issue #10181) that led to a complete rewrite
> > of memoryobject.c.
> >
Big +1
On Feb 26, 2012 4:41 PM, "Eli Bendersky" wrote:
>
> On Sat, Feb 25, 2012 at 12:20, "Martin v. Löwis" wrote:
>
>> > 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 it's because I use it
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" wrote:
> We have two similar proposals, PEPs 407 and 413, to speed up the release
> of at least
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" wrote:
>
>
> On Fri, Feb 24, 2012 at 21:08, Matt Joiner wrote:
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 in
On Mon, Feb 20, 2012 at 11:27 PM, Antoine Pitrou 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,
> short of redoi
+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
insta
+1
On Feb 4, 2012 8:37 PM, "Paul Moore" wrote:
>
> On 4 February 2012 11:25, Steven D'Aprano 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 such modules should have a
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:
http://mail.pyt
Analysis paralysis commence. +1 for separate module using decimal.
On Feb 1, 2012 1:44 PM, "PJ Eby" wrote:
> On Tue, Jan 31, 2012 at 7:35 PM, Nick Coghlan wrote:
>
>> Such a protocol can easily be extended to any other type - the time
>> module could provide conversion functions for integers and
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
separate
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
the
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
Unsubscribe:
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, "N
> __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 no
> +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 t
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 wrote:
> On Fri, Jan 27, 2012 at 12:26 PM, Alex wrote:
>> I think a significa
On Fri, Jan 27, 2012 at 12:26 PM, Alex 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 perspective,
> and
> 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
+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
Python-Dev@python.org
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. Stackle
Can calls to the C types in the io module be made into module lookups
more akin to how it would work were it written in Python? The C
implementation for io_open invokes the C type objects for FileIO, and
friends, instead of looking them up on the io or _io modules. This
makes it difficult to subcla
> 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 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 construct to
>> update
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 enhan
On Wed, Jan 18, 2012 at 6:55 PM, Georg Brandl 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
> maintained is
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
thi
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
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 wrote:
> I marked PEP 380 as Final this evening, after pushing the tested and
> documented implementation to hg.python.org:
> http://hg.python.org/cpython/r
On Thu, Jan 12, 2012 at 11:01 AM, Mike Meyer wrote:
> On Wed, 4 Jan 2012 00:07:27 -0500
> PJ Eby wrote:
>
>> On Tue, Jan 3, 2012 at 7:40 PM, Mike Meyer wrote:
>> > A suite is marked
>> > as a `transaction`, and then when an unlocked object is modified,
>> > instead of indicating an error, a lock
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 wrote:
> Matt J
http://semver.org/
This has made sense since Gentoo days.
On Tue, Jan 10, 2012 at 11:57 PM, Antoine Pitrou wrote:
> On Tue, 10 Jan 2012 08:49:04 +
> Rob Cliffe wrote:
>> But "minor version" and "major version" are readily understandable to
>> the general reader, e.g. me, whereas "feature re
Perhaps the python-dev mailing list should be renamed to python-core.
On Tue, Jan 10, 2012 at 7:35 PM, Stefan Behnel wrote:
> Hi,
>
> sorry for hooking into this off-topic thread.
>
> Amaury Forgeot d'Arc, 09.01.2012 19:09:
>> 2012/1/9
>>> I am trying to send a tuple to a method of a python clas
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
> 2012/1/7 Charl
_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
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
> Hi
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. Löw
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 wrote:
> On Thu, 22 Dec 2011 01:49:37 +
> Michael Foord wrote:
>> These figures can't
ಠ_ಠ
On Sat, Dec 17, 2011 at 8:55 PM, Michael Mueller
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) {
> Py_XINCREF(type);
> desc
standpoint of not
> intersparsing readable code with unnatural characters.
>
> On Sat, Dec 10, 2011 at 09:40:54AM +1100, 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 b
I second this. The doco is very bad.
On Dec 10, 2011 6:34 AM, "Bill Janssen" wrote:
> Xavier Morel 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 reasons to use minidom for produ
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" wrote:
> On Fri, Dec 09, 2011 at 02:21:42PM -0800, Guido van Rossum
+1
On Sat, Dec 10, 2011 at 2:09 AM, Dirkjan Ochtman wrote:
> On Fri, Dec 9, 2011 at 09:02, Stefan Behnel 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" status as a separate
>> librar
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 wrote:
> Such code still won't work on 3.2, hence restoring
This is very interesting, cheers for the link.
On Tue, Dec 6, 2011 at 8:55 PM, Armin Rigo wrote:
> Hi,
>
> Actually, not even one month ago, Intel announced that its processors
> will offer Hardware Transactional Memory in 2013:
>
> http://www.h-online.com/newsticker/news/item/Processor-Whispers-
M, Armin Rigo wrote:
> Hi,
>
> On Thu, Dec 1, 2011 at 07:06, Matt Joiner 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&#x
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 wrote:
> On Thu, Dec
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 wrote:
> 2011/11/30 Matt Joiner :
>> Given GCC's announcement that Intel's STM will be an extension for C
>> and C++ in GCC 4.7, what does this mean
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 gr
Congrats, this is an excellent feature.
On Wed, Nov 30, 2011 at 10:34 AM, Amaury Forgeot d'Arc
wrote:
> 2011/11/29 Nadeem Vawda
>>
>> I'm pleased to announce that as of changeset 74d182cf0187, the
>> standard library now includes support for the LZMA compression
>> algorithm
>
>
> Congratulation
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 deprecated
On Mon, Nov 28, 2011 at 11:14 PM, Steven D'Aprano 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 (as Depreca
I was under the impression this is already in 3.3?
On Nov 25, 2011 10:58 PM, "Eli Bendersky" 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 % slower)
On Fri, Nov 25, 2011 at 10:04 PM, Antoine Pitrou wrote:
> On Fri, 25 Nov 2011 20:34:21 +1100
> Matt Joiner 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
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 5:41 PM, Eli Bendersky 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 avoiding
On Fri, Nov 25, 2011 at 12:07 PM, Antoine Pitrou wrote:
> On Fri, 25 Nov 2011 12:02:17 +1100
> Matt Joiner 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
>&g
ot;top-posting" am I guilty of this? Gmail
defaults to putting my response above the previous email.
On Fri, Nov 25, 2011 at 11:49 AM, Matt Joiner wrote:
> Eli,
>
> Example coming shortly, the differences are quite significant.
>
> On Fri, Nov 25, 2011 at 9:41 AM, Eli Bendersky
Eli,
Example coming shortly, the differences are quite significant.
On Fri, Nov 25, 2011 at 9:41 AM, Eli Bendersky wrote:
> On Fri, Nov 25, 2011 at 00:02, Matt Joiner wrote:
>>
>> What if you broke up the read and built the final string object up. I
>> always assumed t
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" wrote:
> On Thu, Nov 24, 2011 at 20:29, Antoine Pitrou wrote:
>
>> On Thu, 24 Nov 2011 20:15:25 +0200
>> Eli Bendersky wr
98 matches
Mail list logo
