Re: [Python-Dev] ABCs and MRO

On Mon, Mar 2, 2009 at 2:41 AM, Paul Moore wrote: > ... > More generally, there is NO WAY to determine the list of classes for > which issubclass(C, x) is true. > > This could be considered a limitation of, or a bug in, ABCs, I don't > have a particular opinion on that, but it does mean that no co

Re: [Python-Dev] ABCs and MRO

On Mon, Mar 2, 2009 at 1:14 PM, Paul Moore wrote: > 2009/3/2 Jeffrey Yasskin : >> I tend to think it's a bug in ABCs. You seem to have thought of >> several possible ways to fix it, and I don't have strong preferences >> between them. > > I've discusse

[Python-Dev] Evaluated cmake as an autoconf replacement

I've heard some good things about cmake — LLVM, googletest, and Boost are all looking at switching to it — so I wanted to see if we could simplify our autoconf+makefile system by using it. The biggest wins I see from going to cmake are: 1. It can autogenerate the Visual Studio project files instea

Re: [Python-Dev] Evaluated cmake as an autoconf replacement

On Sun, Mar 29, 2009 at 1:14 PM, David Cournapeau wrote: > About cmake: I haven't looked at it recently, but I have a bit of hard > time believing python requires more from a build system than KDE. The > lack of autoheader is not accurate, if > only because kde projects have it: > > http://www.cma

Re: [Python-Dev] PyDict_SetItem hook

On Fri, Apr 3, 2009 at 12:28 PM, Michael Foord wrote: > Collin Winter wrote: >> >> On Fri, Apr 3, 2009 at 2:27 AM, Antoine Pitrou >> wrote: >> >>> >>> Thomas Wouters python.org> writes: >>> Pystone is pretty much a useless benchmark. If it measures anything, it's the >>> >>>

Re: [Python-Dev] PyDict_SetItem hook

On Thu, Apr 2, 2009 at 5:57 PM, Guido van Rossum wrote: > On Thu, Apr 2, 2009 at 3:07 PM, Raymond Hettinger wrote: >>> Wow. Can you possibly be more negative? >> >> I think it's worse to give the poor guy the run around > > Mind your words please. > >> by making him run lots of random benchmarks.

Re: [Python-Dev] Rethinking intern() and its data structure

On Thu, Apr 9, 2009 at 6:24 PM, John Arbash Meinel wrote: > Greg Ewing wrote: >> John Arbash Meinel wrote: >>> And the way intern is currently >>> written, there is a third cost when the item doesn't exist yet, which is >>> another lookup to insert the object. >> >> That's even rarer still, since

Re: [Python-Dev] [unladen-swallow] PEP 384: Defining a Stable ABI

On Wed, May 20, 2009 at 10:34 AM, Antoine Pitrou wrote: > Jeffrey Yasskin gmail.com> writes: >> >> Sorry, I didn't mean to get into a GIL debate. All I'm saying is that >> I don't think changing the definition of Py_INCREF and Py_DECREF >> justifie

Re: [Python-Dev] [unladen-swallow] PEP 384: Defining a Stable ABI

A couple thoughts: I'm with the people who think the refcount should be accessed through functions by apps that want ABI compatibility. In particular, GIL-removal efforts are guaranteed to change how the refcount is modified, but there's a good chance they wouldn't have to change the API. (We have

[Python-Dev] Documenting lnotab

Hi all. I've got a patch to add some documentation for lnotab and its use in tracing at http://bugs.python.org/issue6042. I think it's correct, but it's complicated so I'm looking for someone who was around when it was designed to check. I'm also proposing a change to the semantics of PyCode_Check

Re: [Python-Dev] [unladen-swallow] PEP 384: Defining a Stable ABI

On Wed, May 20, 2009 at 10:14 AM, Antoine Pitrou wrote: > Jeffrey Yasskin gmail.com> writes: >> >> Over an 8-year lifetime for Python 3, Moore's law predicts that >> desktop systems will have up to 64 cores, at which point even the >> simplest GIL-removal strat

Re: [Python-Dev] [Fwd: Re: PEP 384: Defining a Stable ABI]

On Tue, May 19, 2009 at 2:09 AM, William Reade wrote: > (for example, all(?) PyCxx modules use PyCode_New and > PyFrame_New to get nicer tracebacks) Specifically for this, I think it'd be nice to expose a function to do this directly. I recently added PyCode_NewEmpty (http://svn.python.org/view?v

Re: [Python-Dev] Reworking the GIL

y to gil_drop_request, since it's a single variable > (and, moreover, only a single bit of it is significant). > > (there's an explanation of memory ordering issues here: > http://www.linuxjournal.com/article/8211) > > As a side note, I remember Jeffrey Yasskin trying t

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Wed, Jan 20, 2010 at 5:56 PM, Collin Winter wrote: > On Wed, Jan 20, 2010 at 5:14 PM, Terry Reedy wrote: >> Given the slight benefits compared to the costs, I think this, in its >> current state, should be optional, such as is psyco. >> >> Psyco has a similar time-space tradeoff, except that t

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Thu, Jan 21, 2010 at 10:09 AM, Hanno Schlichting wrote: > I'm a relative outsider to core development (I'm just a Plone release > manager), but'll allow myself a couple of questions. Feel free to > ignore them, if you think they are not relevant at this point :-) I'd > note that I'm generally e

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Thu, Jan 21, 2010 at 3:49 PM, Barry Warsaw wrote: > Martin's follow up reminds me what the issues with C++ here are.  They center > around which C++ compilers you use on which platforms.  Solaris, and to some > extent Windows IIRC, were the most problematic for the work I was doing 3+ > years a

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Mon, Jan 25, 2010 at 10:44 AM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Collin Winter wrote: > >> For reference, what are these "obscure platforms" where static >> initializers cause problems? > > It's been a long while since I had to deal with it, but the "usual

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Mon, Jan 25, 2010 at 1:50 PM, "Martin v. Löwis" wrote: >> We really do need precise descriptions of the problems so we can avoid them. > > One family of problems is platform lack of initializer support in the > object file format; any system with traditional a.out (or b.out) is > vulnerable (al

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Wed, Jan 27, 2010 at 11:16 AM, Collin Winter wrote: > We absolutely do not want CPython to include a copy of LLVM in its > source tree. Unladen Swallow has done this to make it easier to pick > up changes to LLVM's codebase as we make them, but this is not a > viable model for CPython's long-te

Re: [Python-Dev] patch to make list.pop(0) work in O(1) time

On Wed, Jan 27, 2010 at 2:14 PM, Daniel Stutzbach wrote: > On Wed, Jan 27, 2010 at 3:49 PM, Raymond Hettinger > wrote: >> >> Also, am not sure if this affects psyco or the other >> implementations such as Jython which may implement >> lists in terms of existing Java containers. > > Or Unladen Swa

Re: [Python-Dev] PEP 3147: PYC Repository Directories

On Sat, Jan 30, 2010 at 8:22 PM, Vitor Bosshard wrote: > 2010/1/31 Nick Coghlan : > >>> Can't a VCS be configured to ignore a .pyr directory just as easily as >>> it can be configured to ignore a .pyc file? >> >> Yes they can. > > > Of course they can, but not out of the box. It was just an exampl

Re: [Python-Dev] PEP 3147: PYC Repository Directories

+1 overall. I'm certainly not concerned with replacing pyc clutter with pyr clutter. I do like that you haven't _increased_ the number of extraneous siblings of .py files. I have a couple bikesheddy or "why didn't you do this" comments. I'll be perfectly satisfied with an answer or a line in the p

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 2:54 PM, Antoine Pitrou wrote: > Le Fri, 5 Mar 2010 17:03:02 +1100, > Brian Quinlan a écrit : >> >> The PEP lives here: >> http://python.org/dev/peps/pep-3148/ > > Ok, here is my take on it: > >> cancel() >> >> Attempt to cancel the call. If the call is currently being exec

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 10:11 PM, Phillip J. Eby wrote: > I'm somewhat concerned that, as described, the proposed API ... [creates] yet > another alternative (and > mutually incompatible) event loop system in the stdlib ... Futures are a blocking construct; they don't involve an event loop. _

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 9:47 PM, Stephen J. Turnbull wrote: > Guido van Rossum writes: > >  > "Future" is a pretty standard CS term for this concept (as noted >  > "promise" is another), > > I like the term "promise" better.  "Future" is very generic ("not now, > but later"), whereas a "promise" is

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Sun, Mar 7, 2010 at 7:48 AM, P.J. Eby wrote: > At 02:49 PM 3/7/2010 +1000, Nick Coghlan wrote: >> >> P.J. Eby wrote: >> > (Personally, I think it would be better to just drop the ambitious title >> > and scope, and go for the "nice task queue" scope.  I imagine, too, that >> > in that case Jean

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Sun, Mar 7, 2010 at 9:57 AM, P.J. Eby wrote: > At 08:39 AM 3/7/2010 -0800, Jeffrey Yasskin wrote: >> Do you have an example of a language or library that uses the term >> "future" to refer to what you're talking about? I'm curious to see >> what it look

Re: [Python-Dev] C++

On Fri, Mar 12, 2010 at 2:18 PM, Neil Hodgson wrote: > Antoine Pitrou: > >> Is this concern still valid? We are in the 2010s now. >> I'm not saying I want us to put some C++ in the core interpreter, but >> the portability argument sounds a little old... > >   There are still viable platforms which

Re: [Python-Dev] C++

On Fri, Mar 12, 2010 at 7:54 PM, wrote: >    Antoine> s...@pobox.com a écrit : >    >> >    >> Traditionally Python has run on some (minority) platforms where C++ >    >> was unavailable. > >    Antoine> Is this concern still valid? We are in the 2010s now. > > Like I said, *minority* platforms.

Re: [Python-Dev] Mixing float and Decimal -- thread reboot

On Sat, Mar 20, 2010 at 4:20 PM, Greg Ewing wrote: > Adam Olsen wrote: > >> For a little context, we have this numeric tower: >> >> int -> Fraction -> float -> complex >> >> Decimal is more precise, and pays a performance cost for it.  It also >> seems odd to stick it between float and complex (no

Re: [Python-Dev] Mixing float and Decimal -- thread reboot

On Wed, Mar 24, 2010 at 2:09 PM, Mark Dickinson wrote: > Slight change of topic.  I've been implementing the extra comparisons > required for the Decimal type and found an anomaly while testing. > Currently in py3k, order comparisons (but not ==, !=) between a > complex number and another complex,

Re: [Python-Dev] HEADS UP: Compilation risk with new GCC 4.5.0

On Wed, May 12, 2010 at 6:39 AM, James Y Knight wrote: > I think you'll be a lot happier just modifying Psyco than making everyone > else in the world change their compiler flags. Aye, there's the rub. Nobody's happier modifying Psyco. :) But that just means people will gradually have to stop us

Re: [Python-Dev] PEP 3148 ready for pronouncement

I think the PEP's overall API is good to go. On Sat, May 22, 2010 at 4:12 PM, Brian Quinlan wrote: > > On 22 May 2010, at 23:59, R. David Murray wrote: >> If there is still discussion then perhaps the PEP isn't ready for >> pronouncement yet.  At some point someone can decide it is all >> bikeshe

Re: [Python-Dev] PEP 3148 ready for pronouncement

On Sat, May 22, 2010 at 4:12 PM, Brian Quinlan wrote: > Rename "executor" => "executer" -1 for consistency with Java. > Rename "submit" to "apply" "apply" focuses attention on the function object, while "submit" focuses attention, properly I think, on the fact that you're handing something to t

Re: [Python-Dev] PEP 3148 ready for pronouncement

On Wed, May 26, 2010 at 3:57 AM, Greg Ewing wrote: > Having read through the PEP again, here are my thoughts. > > * I'm bothered by the term "future". To my mind, it's > too long on cleverness and too short on explanativeness. > > I think that the standard library is no place for > cuteness of nam

Re: [Python-Dev] PEP 3148 ready for pronouncement

On Thu, May 27, 2010 at 8:06 PM, Brian Quinlan wrote: > > On May 28, 2010, at 11:57 AM, Reid Kleckner wrote: > >> On Thu, May 27, 2010 at 4:13 AM, Brian Quinlan wrote: >>> >>> Keep in mind that this library magic is consistent with the library magic >>> that the threading module does - unless the

Re: [Python-Dev] what environment variable should contain compiler warning suppression flags?

On Sat, Jun 26, 2010 at 4:37 PM, M.-A. Lemburg wrote: > Brett Cannon wrote: >> On Wed, Jun 23, 2010 at 14:53, Brett Cannon wrote: >>> I finally realized why clang has not been silencing its warnings about >>> unused return values: I have -Wno-unused-value set in CFLAGS which >>> comes before OPT

Re: [Python-Dev] what environment variable should contain compiler warning suppression flags?

On Sun, Jun 27, 2010 at 1:04 PM, Mark Dickinson wrote: > On Sun, Jun 27, 2010 at 6:46 AM, Jeffrey Yasskin wrote: >> AC_PROG_CC is the macro that sets CFLAGS to -g -O2 on gcc-based >> systems >> (http://www.gnu.org/software/hello/manual/autoconf/C-Compiler.html#index-A

Re: [Python-Dev] New regex module for 3.2?

On Fri, Jul 9, 2010 at 7:06 AM, anatoly techtonik wrote: > On Thu, Jul 8, 2010 at 10:52 PM, MRAB wrote: >> Hi all, >> >> I re-implemented the re module, adding new features and speed >> improvements. It's available at: >> >>    http://pypi.python.org/pypi/regex >> >> under the name "regex" so tha

Re: [Python-Dev] Behaviour of max() and min() with equal keys

On Tue, Sep 7, 2010 at 1:44 PM, Mark Dickinson wrote: > On Tue, Sep 7, 2010 at 8:34 PM, Matthew Woodcraft > wrote: >> In CPython, the builtin max() and min() have the property that if there >> are items with equal keys, the first item is returned. From a quick look >> at their source, I think thi

Re: [Python-Dev] Behaviour of max() and min() with equal keys

On Tue, Sep 7, 2010 at 2:40 PM, Jeffrey Yasskin wrote: > On Tue, Sep 7, 2010 at 1:44 PM, Mark Dickinson wrote: >> On Tue, Sep 7, 2010 at 8:34 PM, Matthew Woodcraft >> wrote: >>> In CPython, the builtin max() and min() have the property that if there >>> are item

Re: [Python-Dev] Support for async read/write

On Tue, Oct 19, 2010 at 8:37 PM, Glyph Lefkowitz wrote: > I'd like to echo this sentiment.  This is not about providing a 'safe' > wrapper to hide some powerful feature of these APIs: the POSIX aio_* > functions are really completely useless. > To quote the relevant standard >

Re: [Python-Dev] Support for async read/write

On Wed, Oct 20, 2010 at 2:55 PM, Glyph Lefkowitz wrote: > > On Oct 20, 2010, at 12:31 AM, Jeffrey Yasskin wrote: > > No comment on the rest of your claim, but this is a silly argument. > The standard says the same thing about at least fcntl.h, signal.h, > pthread.h, and ucontex

Re: [Python-Dev] Format factories (was Re: sWAPcASE Was: transform() and untransform() methods, and the codec registry)

On Sat, Dec 11, 2010 at 11:21 AM, Brett Cannon wrote: > On Thu, Dec 9, 2010 at 16:26, Nick Coghlan wrote: >> On Fri, Dec 10, 2010 at 9:29 AM, Antoine Pitrou wrote: >>> On Thu, 09 Dec 2010 18:10:38 -0500 >>> Eric Smith wrote: If we're looking to reduce the number of methods on str, I wouldn

[Python-Dev] Return type of round, floor, and ceil in 2.6

stency and compatibility with 3.0 suggest that they should return long for every new type we add them to. What does the list think? Thanks, Jeffrey Yasskin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscr

Re: [Python-Dev] Return type of round, floor, and ceil in 2.6

the conversion routines seems to be rare, it's probably best to have it return floats too. -- Namasté, Jeffrey Yasskin ___ 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

Re: [Python-Dev] Return type of round, floor, and ceil in 2.6

On Jan 4, 2008 4:40 AM, Facundo Batista <[EMAIL PROTECTED]> wrote: > 2008/1/4, Jeffrey Yasskin <[EMAIL PROTECTED]>: > > > I haven't seen any answers to the original question. It looks like > > Decimal is decided by 2.5 too: return a float from everything. > &

Re: [Python-Dev] long(float('nan')) conversion

thought math.floor() was to return an int? Or do I misremember?) That's correct. It's currently broken, but I was waiting to push on http://bugs.python.org/issue1656 until the backport was figured out. -- Namasté, Jeffrey Yasskin ___ Python

Re: [Python-Dev] Return type of round, floor, and ceil in 2.6

On Jan 4, 2008 8:50 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Jan 4, 2008 12:13 AM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote: > > On Jan 3, 2008 10:37 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > > Well, as issue 1689 states, the

Re: [Python-Dev] Return type of round, floor, and ceil in 2.6

+``round`` will continue to return floats. ``complex.__{divmod,mod,floordiv,int,float}__`` also go away. It would be nice to provide a nice error message to help confused porters, but -- Namasté, Jeffrey Yasskin ___ Python-Dev mailing list Python

Re: [Python-Dev] Repeatability of looping over dicts

oncurrentDict class would probably be a better way to integrate ConcurrentHashMap. -- Namasté, Jeffrey Yasskin ___ 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

[Python-Dev] Rounding Decimals

ich I'll update as soon as this thread comes to a conclusion. Other people who are interested in getting this right should add themselves to its nosy list so they can object before I check something dumb in. :) I currently plan to keep __round__ in 2.6's Decimal with 3.0's behavior beca

Re: [Python-Dev] Rounding Decimals

on.org/issue1623 tomorrow so we have something concrete to talk about. -- Namasté, Jeffrey Yasskin ___ 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

Re: [Python-Dev] Return type of round, floor, and ceil in 2.6

to but less explicit than ``trunc()``, let's remove it. (Or, if that breaks too much, just add a -- Namasté, Jeffrey Yasskin ___ 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

Re: [Python-Dev] Rounding Decimals

On Jan 6, 2008 1:21 AM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote: > On Jan 5, 2008 7:11 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > > I think pep 3141's round(x, ndigits) does (1). The only thing it > > > doesn't support yet is specifying the

Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages

in. People will just have to get used to the package, and not the namespace, determining who to complain to. In theory, it might make sense to allow libraries to "close" some namespaces to deal with Brett's worry, but I think the consenting adults rule says not to bother. -- Namasté

Re: [Python-Dev] Rounding Decimals

ecessary for 2.6, but they will be needed for 3.0. I'd rather not make the two versions of Decimal gratuitously different, so this patch puts them in the 2.6 version too. That's basically all of the changes in this patch, so I'm not sure exactly what you're objecting to. Co

Re: [Python-Dev] Rounding Decimals

On Jan 6, 2008 7:40 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Jeffrey Yasskin] > > The other 3 methods > > specified by PEP 3141 aren't strictly necessary for 2.6, but they will > > be needed for 3.0. I'd rather not make the two versions of Decima

Re: [Python-Dev] Rounding Decimals

On Jan 6, 2008 10:51 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Jeffrey Yasskin] > >> > I'm not > >> > sure exactly what you're objecting to. Could you be more precise? > >> > >> You note said: "I'll implement Context.

Re: [Python-Dev] Rounding Decimals

ng methods mentioned on this thread. -- Namasté, Jeffrey Yasskin ___ 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

Re: [Python-Dev] Rounding Decimals

On Jan 12, 2008 8:21 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On Jan 12, 2008 5:09 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote: > > During the discussion about the new Rational implementation > > (http://bugs.python.org/issue1682), Guido and Raymond decid

Re: [Python-Dev] Rounding Decimals

ir denominators. That is, to me, the ABCs a type implements are more about how developers should think about the type than the implementation of the type. [ A new thread is probably appropriate if anyone wants to discuss the philosophy, but I probably won't participate... ] -- Namasté, Jeffrey Y

[Python-Dev] Rational approximation methods

In the Rational class that I've recently checked into Python 2.6 (http://bugs.python.org/issue1682), it might be nice to provide a method that, given a particular rational number, returns a nearby number that's nicer in some way. I know of two reasonable behaviors for this operation. Since I don't

Re: [Python-Dev] Rational approximation methods

On Jan 20, 2008 5:54 PM, Tim Peters <[EMAIL PROTECTED]> wrote: > What would be useful is a method that generates (i.e., a generator in > the Python sense) the (continued fraction) convergents to a rational. > People wanting specific constraints on a rational approximation > (including, but not limi

Re: [Python-Dev] trunc()

you intend. In 2.6, that list only includes trunc(). If you absolutely need an int (the concrete, not duck type) from an Integral or you want to parse a string, use int(). Real numbers should define __trunc__. Integrals and, perhaps, some string-like types (maybe an MD5 class?) should define __int__. A

Re: [Python-Dev] trunc()

ented. I think the decision was that removing float.__int__() would break too much, so it needs a deprecation warning in 3.0. int has to be a builtin because it's a fundamental type. trunc() followed round() into the builtins. I have no opinion on whether ceil and floor should move there;

Re: [Python-Dev] Float --> Integer Ratio

ary_float_to_ratio(-.25) > (-1, 4) > """ > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.

Re: [Python-Dev] Organization of ABC modules

the type in the isinstance() call to see if the code was > legitimate. That's a good point. Someone already convinced me to name the test for numbers.py, test_abstract_numbers.py, so renaming the module makes sense too, although I agree that collections, which contains some concrete cl

Re: [Python-Dev] trunc()

On Jan 25, 2008 9:45 AM, Facundo Batista <[EMAIL PROTECTED]> wrote: > 2008/1/25, Jeffrey Yasskin <[EMAIL PROTECTED]>: > > > decision comes to be that int(float) should be blessed as a correct > > way to truncate a float, I'd agree with Raymond that trunc() is

Re: [Python-Dev] trunc()

On Jan 25, 2008 5:53 AM, Paul Moore <[EMAIL PROTECTED]> wrote: > On 24/01/2008, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote: > > int has to be a builtin because it's a fundamental type. trunc() > > followed round() into the builtins. I have no opinion on whether ceil

Re: [Python-Dev] trunc()

but you have to specify how you want it done by using > > trunc() or round() or ceil() or floor(). (In 3.0, round(x) will return > > an int, not a float.) > > > 2008/1/24, Jeffrey Yasskin <[EMAIL PROTECTED]>: > > > That needs to be updated and implemented. I thi

Re: [Python-Dev] trunc()

t you intend? -- Namasté, Jeffrey Yasskin ___ 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

Re: [Python-Dev] trunc()

d as soon as practical (with an error message similar to float(complex)). Could one of the people in favor of keeping both explain why they think that's a good idea? -- Namasté, Jeffrey Yasskin ___ Python-Dev mailing list Python-Dev@python.org http://m

Re: [Python-Dev] trunc()

(well, deprecating) backwards compatibility to achieve a more consistent set of functions in this case. I think it is, but I'm happy to leave that point up to the rest of the list (which does seem to be leaning against it). -- Namasté, Jeffrey Yasskin ___ P

Re: [Python-Dev] trunc()

lly wanted. It's not that they're confused; it's that they're accepting a default that shouldn't be a default. Your other points seem to have been answered already, although people will disagree on how compelling the answers are, so I won't repeat them here. -- Namas

Re: [Python-Dev] trunc()

ould be as easy to make some formatting conversions raise a warning on float inputs as it would be to make int() do it. But I think you're safe here; it doesn't look like either will be deprecated. -- Namasté, Jeffrey Yasskin http://jeffrey.yasskin.info/

Re: [Python-Dev] trunc()

ame numbers or even 'truncate toward zero' got a > blank stare, which did not surprise me too much as it is not a common > (American) English word. You asked a different question than the one we're talking about. You should have asked your 13-yea

Re: [Python-Dev] Tracker marks my messages as spam :-)

On Feb 1, 2008 6:43 AM, Nicko van Someren <[EMAIL PROTECTED]> wrote: > Perhaps it has to do with the low signal to noise ratio of your > messages... That was a little uncalled for. Be polite. ___ Python-Dev mailing list Python-Dev@python.org http://mail.

Re: [Python-Dev] Python on non IEEE-754 platforms: plea for information.

wer on a buildbot. Actually, an even better way to do this would be to craft a test case that exposes the assumptions you've found about the floating format. Then it'll be a valuable regression test even after someone fixes the bug. -- Namasté, Jeffrey Yasskin _

Re: [Python-Dev] Adding __format__ to classic classes

so it won't find __format__ overrides. > > > > Okay, I see and understand that issue. But looking at len or getattr, I > don't see how to generalize it to __format__. __len__ and __getattr__ > have special support in the classes, with cl_getattr, tp_getattr, etc. > &

Re: [Python-Dev] Adding __format__ to classic classes

Oops, sorry for the spam. I didn't see that there were already answers in the rest of the thread. :-( On Feb 13, 2008 9:25 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote: > On Feb 13, 2008 1:42 PM, Eric Smith <[EMAIL PROTECTED]> wrote: > > Guido van Rossum wrote: > &

Re: [Python-Dev] Use Python 3.0 syntax for except and raise?

; Thanks! > > Christian > > ___ > 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/jyasskin%40gmail.com >

Re: [Python-Dev] Py_CLEAR to avoid crashes

On Feb 16, 2008 3:12 PM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote: > Should we however intensively search and correct all of them? > Is there a clever way to prevent these problems globally, for example > by delaying finalizers "just a little"? A simple way to do this would be to push object

Re: [Python-Dev] Py_CLEAR to avoid crashes

On Feb 17, 2008 12:29 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Jeffrey Yasskin wrote: > > On Feb 16, 2008 3:12 PM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote: > >> Should we however intensively search and correct all of them? > &g

Re: [Python-Dev] signal.alarm(3) in trunk test_socketserver.py

if proto == socket.AF_INET: > @@ -267,4 +270,4 @@ > > > if __name__ == "__main__": > test_main() > -signal.alarm(3) # Shutdown shouldn't take more than 3 seconds. > +signal_alarm(3) # Shutdown shouldn't take more than 3 seconds. > > > _

[Python-Dev] Optimizing with.

I've got a patch in http://bugs.python.org/issue2179 that optimizes the bytecode generated by a with statement by tucking the context_manager.__exit__ method onto the stack. It saves 2 opcodes, 8 bytes, and about .5us for each with block at the cost of an extra stack entry for the duration of the b

Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses

one (hopefully with 2.6 warnings) tomorrow. > > Cheers, > > -Gabriel > > P.S. If you were in the sprint room and feel terribly misrepresented, > please feel free to give me a swift kick both on-list and in person > tomorrow morning. > __________

Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses

n 2 > and 3, moreso than any other library. This is convincing for me. Move my +1 back to 3.1. -- Namasté, Jeffrey Yasskin ___ 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

Re: [Python-Dev] [Python-3000] the release gods are angry at python

port in regrtest, although I wouldn't mind having it treat a timeout as a failure, as long as it's easier to diagnose than the SIGKILL it currently uses for timeouts. -- Namasté, Jeffrey Yasskin ___ Python-Dev mailing list Python-Dev@python.o

Re: [Python-Dev] test_signal on osx g4

gt; child_exception = pickle.loads(data) > raise child_exception > break > > Maybe not while True, but try a few times at least. > > Or is the system supposed to automatically restart interrupted system calls? > > Skip > _

Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC

e >> applications of Integral such as the fractions module which accepts any >> integral numerator and denominator. >> >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> http://mail.python.org/mailman/listinf

Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC

ailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/guido%40python.org >> > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > -- Namasté, Jeffrey Yasskin http://jeffrey.yasskin.info/ ___ 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

Re: [Python-Dev] [ANN] VPython 0.1

215ms -34.1% 171ms 248ms -31.3% > WithFinally: 208ms 260ms -20.1% 212ms 271ms -21.9% > WithRaiseExcept: 175ms 193ms -9.0% 186ms 209ms -11.0% > ----------- > Totals:

[Python-Dev] Patch to speed up non-tracing case in PyEval_EvalFrameEx (2% on pybench)

Tracing support shows up fairly heavily an a Python profile, even though it's nearly always turned off. The attached patch against the trunk speeds up PyBench by 2% for me. All tests pass. I have 2 questions: 1) Can other people corroborate this speedup on their machines? I'm running on a Macbook

Re: [Python-Dev] Patch to speed up non-tracing case in PyEval_EvalFrameEx (2% on pybench)

Done: http://bugs.python.org/issue4477 On Sun, Nov 30, 2008 at 8:14 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > Can you toss the patch into the issue tracker, Jeffrey, so that any > patch comments can be done there? > > -Brett > > On Sun, Nov 30, 2008 at 17:54, Jeffrey Y

Re: [Python-Dev] Merging flow

Was there ever a conclusion to this? I need to merge the patches associated with issue 4597 from trunk to all the maintenance branches, and I'd like to avoid messing anyone up if possible. If I don't hear back, I'll plan to svnmerge directly from trunk to each of the branches, and then block my mer

Re: [Python-Dev] Trap SIGSEGV and SIGFPE

On Thu, Dec 11, 2008 at 1:34 AM, Victor Stinner <[EMAIL PROTECTED]> wrote: > But if -as many people wrote- > Python is totally broken after a segfault, it is maybe not a good idea :-) While it's true that after a segfault or unexpected longjmp, there are no guarantees whatsoever about the state of

Re: [Python-Dev] Merging flow

On Thu, Dec 11, 2008 at 4:18 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Martin v. Löwis wrote: >> Jeffrey Yasskin wrote: >>> Was there ever a conclusion to this? I need to merge the patches >>> associated with issue 4597 from trunk to all the maintenance br

Re: [Python-Dev] Merging flow

On Thu, Dec 11, 2008 at 12:10 PM, "Martin v. Löwis" wrote: >> Yeah, that's why I asked. I tried what Martin suggested with r67698 by >> just saying I'd resolved the conflict, which added the single revision >> I was merging from to the svnmerge-integrated property. It didn't add >> the two origina

Re: [Python-Dev] Reindenting the C code base?

On Sun, Dec 14, 2008 at 8:26 AM, Guido van Rossum wrote: > On Sat, Dec 13, 2008 at 2:11 PM, Antoine Pitrou wrote: >> 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. >> >> Wel

  1   2   >