On Tue, Jul 17, 2012 at 3:20 PM, Victor Stinner
victor.stin...@gmail.com wrote:
It's the JIT compiler of Unladen Swallow that failed; in
my understanding because LLVM is crap (i.e. it is slow, memory-consuming,
and buggy) - as a low-level virtual machine; it may be ok as a compiler
backend
FWIW, I'm not sure you're the right person to drive time PEPs. You
don't seem to have come into it with much knowledge of time, and it's
taken several repetitions for you to take corrections into account in
both this discussion and the Decimal/datetime representation PEP.
On Mon, Mar 26, 2012 at
On Fri, Mar 23, 2012 at 4:25 PM, Victor Stinner
victor.stin...@gmail.com wrote:
Hi,
time.steady(strict=True) looks to be confusing for most people, some
of them don't understand the purpose of the flag and others don't like
a flag changing the behaviour of the function.
I propose to replace
On Tue, Mar 13, 2012 at 6:10 PM, Nadeem Vawda nadeem.va...@gmail.com wrote:
On Wed, Mar 14, 2012 at 3:03 AM, Victor Stinner
victor.stin...@gmail.com wrote:
I suppose that most libraries and programs will have to implement a
similar fallback.
We may merge both functions with a flag to be able
On Tue, Mar 13, 2012 at 5:03 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
On 13 Mar 2012, at 16:57, Victor Stinner wrote:
Hi,
I added two functions to the time module in Python 3.3: wallclock()
and monotonic(). I'm unable to explain the difference between these
two functions, even if
On Fri, Feb 3, 2012 at 3:57 AM, Victor Stinner
victor.stin...@haypocalc.com wrote:
datetime.datetime
- as noted earlier in the thread, total_seconds() actually gives you a
decent timestamp value and always returning UTC avoids timezone issues
os.stat() and time.time() use the local time.
On Thu, Feb 2, 2012 at 4:59 PM, Nick Coghlan ncogh...@gmail.com wrote:
datetime.datetime
- real problem with the idea is that not all timestamps can be easily
made absolute (e.g. some APIs may return time since system started
or time since process started)
I think this is an argument for
On Fri, Feb 3, 2012 at 11:17 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 3 Feb 2012 11:04:14 -0800
Jeffrey Yasskin jyass...@gmail.com wrote:
On Thu, Feb 2, 2012 at 4:59 PM, Nick Coghlan ncogh...@gmail.com wrote:
datetime.datetime
- real problem with the idea is that not all
On Wed, Feb 1, 2012 at 5:03 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
datetime.datetime
-
datetime.datetime only supports microsecond resolution, but can be enhanced
to support nanosecond.
datetime.datetime has issues:
- there is no easy way to convert it into
On Wed, Dec 28, 2011 at 5:37 PM, Jesse Noller jnol...@gmail.com wrote:
On Wednesday, December 28, 2011 at 8:28 PM, Michael Foord wrote:
Hello all,
A paper (well, presentation) has been published highlighting security
problems with the hashing algorithm (exploiting collisions) in many
On Sat, Dec 11, 2010 at 11:21 AM, Brett Cannon br...@python.org wrote:
On Thu, Dec 9, 2010 at 16:26, Nick Coghlan ncogh...@gmail.com wrote:
On Fri, Dec 10, 2010 at 9:29 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 09 Dec 2010 18:10:38 -0500
Eric Smith e...@trueblade.com wrote:
If
On Wed, Oct 20, 2010 at 2:55 PM, Glyph Lefkowitz
gl...@twistedmatrix.com 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
On Tue, Oct 19, 2010 at 8:37 PM, Glyph Lefkowitz
gl...@twistedmatrix.com 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
On Tue, Sep 7, 2010 at 1:44 PM, Mark Dickinson dicki...@gmail.com wrote:
On Tue, Sep 7, 2010 at 8:34 PM, Matthew Woodcraft
matt...@woodcraft.me.uk 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
On Tue, Sep 7, 2010 at 2:40 PM, Jeffrey Yasskin jyass...@gmail.com wrote:
On Tue, Sep 7, 2010 at 1:44 PM, Mark Dickinson dicki...@gmail.com wrote:
On Tue, Sep 7, 2010 at 8:34 PM, Matthew Woodcraft
matt...@woodcraft.me.uk wrote:
In CPython, the builtin max() and min() have the property
On Fri, Jul 9, 2010 at 7:06 AM, anatoly techtonik techto...@gmail.com wrote:
On Thu, Jul 8, 2010 at 10:52 PM, MRAB pyt...@mrabarnett.plus.com 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
On Sun, Jun 27, 2010 at 1:04 PM, Mark Dickinson dicki...@gmail.com wrote:
On Sun, Jun 27, 2010 at 6:46 AM, Jeffrey Yasskin jyass...@gmail.com 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
On Sat, Jun 26, 2010 at 4:37 PM, M.-A. Lemburg m...@egenix.com wrote:
Brett Cannon wrote:
On Wed, Jun 23, 2010 at 14:53, Brett Cannon br...@python.org wrote:
I finally realized why clang has not been silencing its warnings about
unused return values: I have -Wno-unused-value set in CFLAGS
On Thu, May 27, 2010 at 8:06 PM, Brian Quinlan br...@sweetapp.com wrote:
On May 28, 2010, at 11:57 AM, Reid Kleckner wrote:
On Thu, May 27, 2010 at 4:13 AM, Brian Quinlan br...@sweetapp.com wrote:
Keep in mind that this library magic is consistent with the library magic
that the threading
On Wed, May 26, 2010 at 3:57 AM, Greg Ewing greg.ew...@canterbury.ac.nz 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
I think the PEP's overall API is good to go.
On Sat, May 22, 2010 at 4:12 PM, Brian Quinlan br...@sweetapp.com 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
On Sat, May 22, 2010 at 4:12 PM, Brian Quinlan br...@sweetapp.com 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
On Wed, May 12, 2010 at 6:39 AM, James Y Knight f...@fuhm.net 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
On Wed, Mar 24, 2010 at 2:09 PM, Mark Dickinson dicki...@gmail.com 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
On Sat, Mar 20, 2010 at 4:20 PM, Greg Ewing greg.ew...@canterbury.ac.nz 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
On Fri, Mar 12, 2010 at 2:18 PM, Neil Hodgson nyamaton...@gmail.com 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
On Fri, Mar 12, 2010 at 7:54 PM, s...@pobox.com 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.
On Sun, Mar 7, 2010 at 7:48 AM, P.J. Eby p...@telecommunity.com 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
On Sun, Mar 7, 2010 at 9:57 AM, P.J. Eby p...@telecommunity.com 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 looks like.
The wikipedia page
On Fri, Mar 5, 2010 at 2:54 PM, Antoine Pitrou solip...@pitrou.net wrote:
Le Fri, 5 Mar 2010 17:03:02 +1100,
Brian Quinlan br...@sweetapp.com 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
On Fri, Mar 5, 2010 at 10:11 PM, Phillip J. Eby p...@telecommunity.com 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
On Sat, Jan 30, 2010 at 8:22 PM, Vitor Bosshard algor...@gmail.com wrote:
2010/1/31 Nick Coghlan ncogh...@gmail.com:
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.
+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
On Wed, Jan 27, 2010 at 11:16 AM, Collin Winter collinwin...@google.com 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
On Wed, Jan 27, 2010 at 2:14 PM, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
On Wed, Jan 27, 2010 at 3:49 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
Also, am not sure if this affects psyco or the other
implementations such as Jython which may implement
lists in
On Mon, Jan 25, 2010 at 10:44 AM, Tres Seaver tsea...@palladion.com 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
On Mon, Jan 25, 2010 at 1:50 PM, Martin v. Löwis mar...@v.loewis.de 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
On Thu, Jan 21, 2010 at 10:09 AM, Hanno Schlichting ha...@hannosch.eu 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
On Thu, Jan 21, 2010 at 3:49 PM, Barry Warsaw ba...@python.org 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
On Wed, Jan 20, 2010 at 5:56 PM, Collin Winter collinwin...@google.com wrote:
On Wed, Jan 20, 2010 at 5:14 PM, Terry Reedy tjre...@udel.edu 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
of memory ordering issues here:
http://www.linuxjournal.com/article/8211)
As a side note, I remember Jeffrey Yasskin trying to specify an ordering model
for Python code
(see http://code.google.com/p/unladen-swallow/wiki/MemoryModel).
Note that that memory model was only for Python code; the C
On Wed, May 20, 2009 at 10:34 AM, Antoine Pitrou solip...@pitrou.net wrote:
Jeffrey Yasskin jyasskin at 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
justifies going to Python 4.0, so I
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
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
On Wed, May 20, 2009 at 10:14 AM, Antoine Pitrou solip...@pitrou.net wrote:
Jeffrey Yasskin jyasskin at 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 strategy of making
On Tue, May 19, 2009 at 2:09 AM, William Reade
will...@resolversystems.com 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
On Thu, Apr 9, 2009 at 6:24 PM, John Arbash Meinel
john.arbash.mei...@gmail.com 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
On Thu, Apr 2, 2009 at 5:57 PM, Guido van Rossum gu...@python.org wrote:
On Thu, Apr 2, 2009 at 3:07 PM, Raymond Hettinger pyt...@rcn.com 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
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
On Sun, Mar 29, 2009 at 1:14 PM, David Cournapeau courn...@gmail.com 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:
On Mon, Mar 2, 2009 at 1:14 PM, Paul Moore p.f.mo...@gmail.com wrote:
2009/3/2 Jeffrey Yasskin jyass...@gmail.com:
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 discussed ways of fixing
On Mon, Mar 2, 2009 at 2:41 AM, Paul Moore p.f.mo...@gmail.com 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
On Mon, Jan 26, 2009 at 2:00 PM, Guido van Rossum gu...@python.org wrote:
On Mon, Jan 26, 2009 at 1:57 PM, Giovanni Bajo ra...@develer.com wrote:
On Mon, 26 Jan 2009 10:31:55 -0800, Guido van Rossum wrote:
On Mon, Jan 26, 2009 at 8:08 AM, Paul Hummer p...@eventuallyanyway.com
wrote:
At a
On Sun, Dec 14, 2008 at 8:26 AM, Guido van Rossum gu...@python.org wrote:
On Sat, Dec 13, 2008 at 2:11 PM, Antoine Pitrou solip...@pitrou.net wrote:
Guido van Rossum guido at python.org writes:
I think we should not do this. We should use 4 space indents for new
files, but existing files
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
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 branches,
and I'd like to avoid messing anyone up
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
:
http://mail.python.org/mailman/options/python-dev/jyasskin%40gmail.com
--
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
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
mailing list
Python-Dev@python.org
http://mail.python.org/mailman/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
://mail.python.org/mailman/options/python-dev/jyasskin%40gmail.com
--
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
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
--
Namasté,
Jeffrey Yasskin
http://jeffrey.yasskin.info/
___
Python-Dev
for
timeouts.
--
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 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
--
Namasté,
Jeffrey Yasskin
http://jeffrey.yasskin.info
,
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
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
@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/jyasskin%40gmail.com
--
Namasté,
Jeffrey Yasskin
http://jeffrey.yasskin.info/
___
Python-Dev mailing list
Python-Dev
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?
Is there a clever way to prevent these problems globally
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/jyasskin%40gmail.com
--
Namasté,
Jeffrey Yasskin
http://jeffrey.yasskin.info/
___
Python-Dev mailing list
Python-Dev@python.org
http
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 objects
, but could you point me to some code that does
something similar but looks up the method by name?
I'm not sure if it'll be exactly analogous, but you might look at
__trunc__ and math.trunc for inspiration.
--
Namasté,
Jeffrey Yasskin
http://jeffrey.yasskin.info
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:
Much to my surprise, this already
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
to an integer. For the first, you'd likely
have gotten the same blank stare. For the second, I expect you'd have
gotten either 4, or an objection that it's simply not an integer and
can't be converted to one.
--
Namasté,
Jeffrey Yasskin
___
Python-Dev mailing
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.
--
Namasté,
Jeffrey Yasskin
___
Python-Dev mailing
either
will be deprecated.
--
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
?
--
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
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://mail.python.org/mailman/listinfo/python-dev
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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
, which contains some
concrete classes, should keep its current name. If others agree, want
to send a patch?
--
Namasté,
Jeffrey Yasskin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
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 just
duplication and should be eliminated. I'd
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
and floor should move
() 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 think the decision was
that removing float.__int__() would break too much, so it needs a
deprecation warning in 3.0
(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__.
At least, that's my suggestion.
--
Namasté,
Jeffrey Yasskin
it's a fundamental type. trunc()
followed round() into the builtins. I have no opinion on whether ceil
and floor should move there; it probably depends on how often they're
used.
--
Namasté,
Jeffrey Yasskin
___
Python-Dev mailing list
Python-Dev@python.org
://mail.python.org/mailman/options/python-dev/jyasskin%40gmail.com
--
Namasté,
Jeffrey Yasskin
http://jeffrey.yasskin.info/
Religion is an improper response to the Divine. — Skinny Legs and
All, by Tom Robbins
___
Python-Dev mailing list
Python-Dev@python.org
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 limited
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
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 decided that
Decimal should not implement
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 Yasskin
___
Python-Dev mailing list
Python
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
a better way to handle the part of Mark's request that the
round builtin doesn't cover. Of course, there may be even better
alternatives that I haven't thought of. I'll post a patch to
http://bugs.python.org/issue1623 tomorrow so we have something
concrete to talk about.
--
Namasté,
Jeffrey Yasskin
, 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
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 rounding mode. Perhaps the pep
should say that round
, 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é,
Jeffrey Yasskin
___
Python-Dev mailing
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. Could you be more precise?
--
Namasté,
Jeffrey Yasskin
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 Decimal
gratuitously different, so this patch puts
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 backporting was commited by Jeffrey on
rev 5967 [2], so
}__`` 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-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
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
1 - 100 of 105 matches
Mail list logo
