> On Sep 11, 2016, at 11:58 AM, Mark Dickinson wrote:
>
>> So I suppose the thing to do is to benchmark stable radix sort against
>> timsort and see if it's still worth it.
>
> Agreed; it would definitely be interesting to see benchmarks for the
> two-array stable sort as well as the American
> On Sep 11, 2016, at 1:37 AM, Victor Stinner wrote:
>
> For Python 3.7, I propose that we move all these private functions in
> separated header files, maybe Include/private/ or Include/core/, and
> not export them as part of the "regular API".
>
> The risk is that too many C extensions rely o
jor block of code accepted
into the Python core but that shouldn't open to floodgates to engaging in more
major rewrites of other datatypes unless we're sure that it is warranted.
Raymond Hettinger
___
Python-Dev mailing list
Python
> On Sep 14, 2016, at 11:31 PM, Serhiy Storchaka wrote:
>
> Note that this is made at the expense of the 20% slowing down an iteration.
>
> $ ./python -m timeit -s "d = dict.fromkeys(range(10**6))" -- "list(d)"
> Python 3.5: 66.1 msec per loop
> Python 3.6: 82.5 msec per loop
A range of consec
[Eric]
>> My understanding is that the all-int-keys case is an outlier. This is due
>> to how ints hash, resulting in fewer collisions and a mostly
>> insertion-ordered hash table. Consequently, I'd expect the above
>> microbenchmark to give roughly the same result between 3.5 and 3.6, which
>>
> On Oct 8, 2016, at 3:01 AM, Serhiy Storchaka wrote:
>
> Since dict is ordered in CPython 3.6, it can be used instead of OrderedDict
> in some places (e.g. for implementing simple limited caches). But since this
> is implementation detail, it can't be used in the stdlib unconditionally.
> Ne
> On Nov 3, 2016, at 3:51 PM, Steven D'Aprano wrote:
>
> Before there can be a solution, there first has to be a problem that
> needs solving. "Lack of consistency" is not necessarily a problem. The
> intertools functions are quite different, they do different things with
> different APIs. Th
> On Nov 22, 2016, at 6:57 AM, Victor Stinner wrote:
>
> Should I revert these changes?
I don't think reverting any of these would improve the release.
I vote for them to stay.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://
> On Nov 25, 2016, at 1:28 AM, Victor Stinner wrote:
>
> I would like to completely remove the feature to be able to implement
> further optimizations.
This seems reasonable to me. I've never used or needed this special build;
StackOverflow has no mention of it; and a Google search comes up n
> On Nov 28, 2016, at 10:36 AM, Serhiy Storchaka wrote:
>
> On 28.11.16 09:06, Benjamin Peterson wrote:
>> I've have just updated PEP 373 to say that Python 2.7.13 release
>> candidate 1 will be released on December 3. The final will follow two
>> weeks later on December 17. If there are delays
> On Dec 5, 2016, at 10:38 AM, Terry Reedy wrote:
>
> I believe that this item in your list is a design choice rather than a bug.
> "* _collectionsmodule.c: deque_repr uses "[...]" as repr if recursion is
> detected. I'd suggest that "deque(...)" is clearer---it's not a list."
>
> I strongly
psort-analysis-part.pdf
If you have other follow-ups, please take this discussion to another list.
This list is for the development of the Python core and not for general
questions about algorithms or use of the language.
Raymond Hettinger
___
P
> On Dec 12, 2016, at 8:12 AM, Raymond Hettinger
> wrote:
>
> The heapify() algorithm is well known and well studied. A quick Google
> search turns up plenty of explanations:
> https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF
> On Dec 13, 2016, at 1:51 AM, Max Moroz wrote:
>
> Would it be worth ensuring that an exception is ALWAYS raised if a key
> is added to or deleted from a dictionary during iteration?
>
> I suspect the cost of a more comprehensive error reporting is not
> worth the benefit, but I thought I'd as
> On Dec 13, 2016, at 8:42 AM, Raymond Hettinger
> wrote:
>
>> On Dec 13, 2016, at 1:51 AM, Max Moroz wrote:
>>
>> Would it be worth ensuring that an exception is ALWAYS raised if a key
>> is added to or deleted from a dictionary during iteration?
&g
> On Dec 16, 2016, at 11:24 AM, Guido van Rossum wrote:
>
> I am beginning to think that `from __future__ import unicode_literals` does
> more harm than good. I don't recall exactly why we introduced it, but with
> the restoration of u"" literals in Python 3.3 we have a much better story for
> On Dec 18, 2016, at 9:26 PM, Larry Hastings wrote:
>
> So, if you have an opinion, please vote for one of these three options:
> • Don't slip 3.5.3. and 3.4.6.
> • Slip 3.5.3 and 3.4.6 by two weeks to match 3.6.0.
> • Slip 3.5.3 and 3.4.6 by a whole month, to give 3.6.0 the a
> On Jan 17, 2017, at 5:16 PM, Victor Stinner wrote:
>
> /* tp_xxx */" lines and make the code much more
> readable! It should help to prevent bugs when the code is modified.
I'm +0 on the change (it is a massive code churn with a huge diff and won't
match any existing C extensions or publish
> On Jan 17, 2017, at 11:41 AM, Roberto Martínez
> wrote:
>
> Oh, I understand. Maybe is not worth the effort anyway.
FWIW, I'm also in the camp of thinking it is not worth the effort. Until there
is a demonstrated need (something than can't be met by checking for __set__),
the default posi
> On Jan 22, 2017, at 6:31 PM, Ramsey D'silva wrote:
>
> Nice to meet all of you'll. I'm excited to learn and hopefully contribute
> someday.
Welcome aboard.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/
> On Mar 1, 2017, at 8:47 AM, Yury Selivanov wrote:
>
>> IMHO this is a good idea*iff* the new APIs really are bound to
>> asyncio, rather than being generic across all uses of async/await.
>
> I agree. There is no need to make asynccontextmanager and
> AsyncExitStack dependent on asyncio or
Yes. It is perfectly reasonable to backport improvements to the tooling as
long as it doesn't break anyone's existing build process.
Sent from my iPhone
> On May 4, 2017, at 10:13 AM, Victor Stinner wrote:
>
> tl;dr Are you ok to backport my change replacing "make touch" with
> "make regen-a
> On Jul 17, 2017, at 6:31 AM, Antoine Pitrou wrote:
>
>> I think I understand well enough to say something intelligent…
>>
>> While actual references to _source are likely rare (certainly I’ve never
>> used it), my understanding is that the way namedtuple works is to
>> construct _source, and
> On Jul 17, 2017, at 8:22 AM, Steve Holden wrote:
>
> My only question is "what's a variable called _source doing in the public
> API?"
The convention for named tuple hnas been for all the methods and attributes to
be prefixed with an underscore so that the names won't conflict with field
n
> On Jul 17, 2017, at 8:49 AM, Guido van Rossum wrote:
>
> The approach of generating source code and exec()ing it, is a cool
> demonstration of Python's expressive power, but it's always been my sense
> that whenever we encounter a popular idiom that uses exec() and eval(), we
> should augm
> On Jul 17, 2017, at 8:49 AM, Guido van Rossum wrote:
>
> One of the reasons to be wary of exec()/eval() other than the usual security
> concerns is that in some Python implementations they have a high overhead to
> initialize the parser and compiler. (Even in CPython it's not that fast.)
BT
> On Jul 21, 2017, at 3:45 AM, Victor Stinner wrote:
>
> Ok, I more concrete problem. To fix the "urllib FTP" bug, we have to
> find a balance between security (reject any URL looking like an
> attempt to counter the security protections) and backward
> compatibility (accept filenames containing
For the benefit of the audience on python-dev, you should also mention that
this proposal and associated PR has been twice discussed and rejected on the
tracker:
https://bugs.python.org/issue45907
https://bugs.python.org/issue45843
The response just given by Skip pretty much matches the c
> I propose to restrict the type of __slots__.
-1 for adding a restriction. This breaks code for no good reason. This
API has been around for a very long time. I've seen lists, tuples, dicts,
single strings, and occasionally something more exotic. Why wreck stable
code?
Also, the inspect modu
Thanks for doing this. I hope it encourages more participation.
The capabilities of a triager mostly look good except for "closing PRs and
issues". This is a superpower that has traditionally been reserved for more
senior developers because it grants the ability to shut-down the work of
anoth
> On Aug 27, 2019, at 10:44 AM, Mariatta wrote:
>
> (cross posting to python-committers, python-dev, core-workflow)
>
> PEP 581: Using GitHub Issues has been accepted by the steering council, but
> PEP 588: GitHub Issues Migration plan is still in progress.
>
> I'd like to hear from core deve
> On Aug 27, 2019, at 10:44 AM, Mariatta wrote:
>
> (cross posting to python-committers, python-dev, core-workflow)
>
> PEP 581: Using GitHub Issues has been accepted by the steering council, but
> PEP 588: GitHub Issues Migration plan is still in progress.
>
> I'd like to hear from core dev
> On Dec 15, 2019, at 6:48 PM, Larry Hastings wrote:
>
> As of 3.7, dict objects are guaranteed to maintain insertion order. But set
> objects make no such guarantee, and AFAIK in practice they don't maintain
> insertion order either. Should they?
I don't think they should.
Several tho
> PyObject_RichCompareBool(x, y, op) has a (valuable!) shortcut: if x and y are
> the same object, then equality comparison returns True and inequality False.
> No attempt is made to execute __eq__ or __ne__ methods in those cases.
>
> This has visible consequences all over the place, but they d
> We propose to revert 5 changes:
>
> • Removed tostring/fromstring methods in array.array and base64 modules
> • Removed collections aliases to ABC classes
> • Removed fractions.gcd() function (which is similar to math.gcd())
> • Remove "U" mode of open(): having to use io
I forget to mention that list.index() also uses PyObject_RichCompareBool().
Given a non-empty list *s*:
s[0] = x
assert s.index(x) == 0 # We want this to always work
or:
s = [x]
assert s.index(x) == 0# Should not raise a ValueError
If those two assertions aren't r
SimpleNamespace() is really good at giving attribute style-access. I would like
to make that functionality available to the JSON module (or just about anything
else that accepts a custom dict) by adding the magic methods for mappings so
that this works:
catalog = json.load(f, object_hook=S
[GvR]
> We should not try to import JavaScript's object model into Python.
Yes, I get that. Just want to point-out that working with heavily nested
dictionaries (typical for JSON) is no fun with square brackets and quotation
marks.
Raymond
___
Pytho
[Serhiy]
> As a workaround you can use
>
> object_hook=lambda x: SimpleNamespace(**x)
That doesn't suffice because some valid JSON keys are not valid identifiers.
You still need a way to get past those when they arise:
catalog.books.fiction['Paradise Lost'].isbn Also, it still leaves you wit
Please consider adding underscores to the names: remove_prefix() and
remove_suffix().
The latter method causes a mental hiccup when first read as removes-uffix,
forcing mental backtracking to get to remove-suffix. We had a similar problem
with addinfourl initially being read as add-in-four-l b
This will be a nice improvement.
Raymond
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.pyt
> t...@tomforb.es wrote:
>
> I would like to suggest adding a simple “once” method to functools. As the
> name suggests, this would be a decorator that would call the decorated
> function, cache the result and return it with subsequent calls.
It seems like you would get just about everything
> On Apr 29, 2020, at 12:55 AM, Tom Forbes wrote:
>
> Hey Raymond,
> Thanks for your input here! A new method wouldn’t be worth adding purely for
> performance reasons then, but there is still an issue around semantics and
> locking.
Right.
> it doesn’t actually ensure the function is calle
> On Apr 29, 2020, at 4:20 PM, Antoine Pitrou wrote:
>
> On Wed, 29 Apr 2020 12:01:24 -0700
> Raymond Hettinger wrote:
>>
>> The call_once() decorator would need different logic:
>>
>> 1) if the function has already been called and result is known, retur
> On Apr 30, 2020, at 6:32 AM, Joao S. O. Bueno wrote:
>
> Of course this is meant to be something simple - so there are no "real
> world use cases" that are "wow, it could not have
> been done without it".
The proposed implementation does something risky, it hold holds a non-reentrant
lock a
Would either of the existing solutions work for you?
class X:
def __init__(self, name):
self.name = name
@cached_property
def title(self):
print("compute title once")
return self.name.title()
@property
@lru_cache
def upper(self):
print("compute u
> On Apr 30, 2020, at 10:44 AM, Carl Meyer wrote:
>
> On Wed, Apr 29, 2020 at 9:36 PM Raymond Hettinger
> wrote:
>> Do you have some concrete examples we could look at? I'm having trouble
>> visualizing any real use cases and none have been presented so far.
> On May 4, 2020, at 10:30 AM, Eric Snow wrote:
>
> Further feedback is welcome, though I feel like the PR is ready (or
> very close to ready) for pronouncement. Thanks again to all.
Congratulations. Regardless of the outcome, you've certainly earned top marks
for vision, tenacity, team pl
> it is hard to make a decision between the pros and cons,
> when the pros are in a single formal document and the
> cons are scattered across the internet.
Mark, I support your idea. It is natural for PEP authors to not fully
articulate the voices of opposition or counter-proposals.
The cu
> On Jun 22, 2020, at 5:10 AM, Victor Stinner wrote:
>
> Introduce C API incompatible changes to hide implementation details.
How much of the existing C extension ecosystem do you expect to break as a
result of these incompatible changes?
> It will be way easier to add new features.
This i
> On Jun 29, 2020, at 5:46 PM, Victor Stinner wrote:
>
> You missed the point of the PEP: "It becomes possible to experiment
> with more advanced optimizations in CPython than just
> micro-optimizations, like tagged pointers."
>
> IMHO it's time to stop wasting our limited developer resources
- Original Message -
From: "Cesare Di Mauro"
To: "Python-Dev"
Sent: Tuesday, February 10, 2009 8:24 AM
Subject: [Python-Dev] Expression optimizations
In peephole.c I noticed some expression optimizations:
/* not a is b --> a is not b
not a in b --> a not in b
not a is not
The online development docs stopped their nightly rebuilds four days ago.
Raymond
___
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/archi
[Cesare Di Mauro]
I'm playing with the virtual machine and I have some ideas about possibile
optimizations that could be applyed. But I need to verify them, so
understanding what is possible and what is not, is a primary goal for me.
The best way to understand what is possible is to disassemble
ISTM, that when closing duplicate bug reports, both should reference one
another so that the combined threads don't get lost.
Also, assigning bugs to people who haven't asked to handle them doesn't seem like it is actually cleaning-up anything. If something
is assigned to someone, I usually as
[Daniel (ajax) Diniz]
Now will I'll start verifying, adding tests, updating or closing as
needed the recently changed old issues, until I've taken a good look
at these. Then, if there's still time left before Saturday, I'll focus
on verifying/flagging more ancient ones.
Thanks for your effort
C:\py27>py27 lib\test\regrtest.py -uall test_tk
test_tk
test test_tk failed -- Traceback (most recent call last):
File "c:\py27\lib\lib-tk\test\test_tkinter\test_text.py", line 32, in
test_search
self.failUnlessEqual(text.search('-test', '1.0', 'end'), '1.2')
AssertionError: != '1.2'
1 test
http://www.latimes.com/news/science/la-sci-satellite-collision15-2009feb15,0,7901281.story
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-de
[Greg Ewing]
I've discovered something slightly misleading in the docs
for PyObject_IsInstance:
When testing if B is a subclass of A, if A is B, PyObject_IsSubclass
returns true. If A and B are different objects, B‘s __bases__
attribute is searched...
This suggests that issubclass(A, A)
If someone sets the -3 option to get py3k warnings, should the classic division
warning get turned-on automatically?
Right now, I get no warnings for:
python -3 -c "9 / 5"
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
[Venkatraman S]
the following line
kind of confuses me and wasnt sure what exactly Raymond(et al) is planning,
I think the AST optimization work is being pursued by tlee.
See his current results on the branch: tlee-ast-optimize/
I don't know if this work has stalled but it was off to a good
[Brett]
With io getting rewritten as an extension module, I think it's time to try to
come up with a good best practice scenario for how to be able to control
when a module uses a pure Python implementation and when it uses
extension module optimizations. This is really only important for test
ed as
dominant.
- Original Message -
From: Brett Cannon
To: Raymond Hettinger
Cc: Python Dev
Sent: Friday, February 20, 2009 12:41 PM
Subject: Re: [Python-Dev] Choosing a best practice solution for
Python/extensionmodules
On Fri, Feb 20, 2009 at 12:33, Raymond Hett
[Chris Withers]
I want to work on these issues:
http://bugs.python.org/issue1823
http://bugs.python.org/issue1874
...and I'd also like to commit the patch I submitted with this one:
http://bugs.python.org/issue1974
Barry usually takes ownership of changes to the email package.
Do you have p
[Chris Withers]
Barry usually takes ownership of changes to the email package.
Do you have patches ready for him to review?
Not yet for 1974, but given that I submitted a patch for this issue:
http://bugs.python.org/issue4308
...some months ago, and nothing has happened with it, I want to ge
> You might also want to collect a list of serious changes that you want
> in this release; I know I/O in C is on the list (and without it I
> wouldn't consider it worth releasing) but there may be others. The
> developers of such features ought to be on board with delivering their
> code before
[Armin Ronacher]
PEP 372 was modified so that it provides a simpler API (only the dict API
to be exact) and it was decided to start with a Python-only implementation
and replace it with a C version later if necessary.
Annotated changes from earlier versions of the PEP:
- the extra API for or
[Antoine Pitrou]
Given you were bitten by it in your own unit tests (the "eval(repr()) does not
maintain ordering" problem pointed by Georg),
Completely unrelated. The original test passed because the arbitrarily
ordered data in the regular dict happened to match the order added in
a regular
[Antoine Pitrou]
You seem to imply that it is more important for __eq__ to work intuitively
between a non-OrderedDict and an OrderedDict, than it is to work intuitively
between two OrderedDicts.
Yes. When Armin and I worked through this, it became clear that
he had multiple use cases where or
But you'll have to convince me,
Okay, here's one stab at it. If it doesn't take, I give in.
ISTM, either way is right depending on your point of view and what
you're trying do at the time. My judgment tips in favor of not
specializing the __eq__ method. But it is not lost on me why
one might
[Me]
In this case, Armin wants to be able to pass in an ordered dictionary to functions that weren't designed with ordered dicts in
mind (config parser, json/yaml parsers, nose, unittest, etc.). Those functions should be able to assume that all the usual
dictionary properties are still true. I
Compromise?
def __eq__(self, other):
if isinstance(other, OrderedDict):
return all(map(operator.eq, self.items(), other.items()))
if isinstance(other, Mapping):
return dict.__eq__(self, other)
return NotImplemented # Give other a chance; defaults to
[GvR]
This sounds fair. Note that dict.__eq__ actually returns
NotImplemented if not isinstance(other, dict) so you could tighten the
test to isinstance(other, dict) if you wanted to.
Okay. Done deal.
Raymond
___
Python-Dev mailing list
Python-Dev@
My preference is OrderedDict.
That says that it is a pure python class like Counter, UserDict, UserList,
MutableMapping and other collections classes.
It is clear and explicit in its intention and doesn't make you try to remember
what the o in odict stands for.
Raymond
/bikeshedding
Yes. Also we need to paint it green with pink polka dots :-)
___
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%40m
[Nick Coghlan]
The examples in the PEP used 'odict' (until recently), but the patch was
for OrderedDict.
As an experiment, try walking down the hall asking a few programmers who aren't in this conversion what they think
collections.odict() is?
Is it a class or function? What does it do? Can
Unfortunately PEP 8 never really took off naming-wise, so we're mostly following
the "reuse the naming scheme from existing code in the same module" rule, and I
think there lowercase wins, thanks to defaultdict.
Traditionally, the all lowercase name referred to a C type. The other classes
in
[GvR]
*Maybe* the "built-in status" should guide the
capitalization, so only built-in types are lowercase (str, int, dict
etc.).
That makes sense.
Anyway, it seems the collections module in particular is already
internally inconsistent -- NamedTuple vs. defaultdict.
FWIW, namedtuple() is a
-
From: "Guido van Rossum"
To: "Raymond Hettinger"
Cc: ; "Armin Ronacher"
Sent: Monday, March 02, 2009 3:38 PM
Subject: Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections
ready for pronouncement
On Mon, Mar 2, 2009 at 3:13 PM, Raymond Hett
[Forest]
Okay, but I'd also like a convenient and fast way to find the oldest entry
in an OrderedDict, which I think I'd need for an LRU cache. Skimming the
current patch (od7.diff), I didn't notice one. Perhaps I simply missed
something. Shouldn't popitem() allow the caller to choose which e
I recommend that you either make this a
__private variable (signalling strongly that people shouldn't ever
reference it),
Will do. We want to make sure we can substitute a C implementation that has a completely different underlying structure (hash table
plus a doubly linked list).
Raymond
[Forest]
Perhaps a new method like getfirst() would be worth while here?
Guido already gave you a way to access the first item using the existing API.
Using next(iter(d)) also works.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://
It may be too late to rename the existing accidents, but why not add
consistently-named aliases (socket.Socket, datetime.DateTime, etc) and
strongly encourage their use in new code?
Or make the old names aliases for the new names and start a
PendingDeprecationWarning on the old names so they c
Perhaps the terminology should be
ordereddict -- what we have here
sorteddict -- hypothetical future type that keeps
itself sorted in key order
+1
FIFOdict ? Yeah, that blows the capitalization scheme, way, way out.
Issues:
* The popitem() method is LIFO.
* In a non
Beware, deleting an item from an OrderedDict (in the current
implementation) is O(N).
Am I correct in presuming that that would not be true of .popitem?
Yes. The popitem() method is O(1).
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
Just notices that the empty() and full() methods were still there.
IIRC, we agreed to take them out (but leaving qsize() exposed).
The docs entries and test cases were taken out, but the actual
methods were accidentally left in.
Raymond
___
Python-Dev m
Just noticed that the empty() and full() methods were still there.
IIRC, we agreed to take them out (but leaving qsize() exposed).
The docs entries and test cases were taken out, but the actual
methods were accidentally left in.
If so, the only thing to do is deprecate it in 3.1 for removal in 3
Yup, I'd need to remove support in multiprocessing too.
ahead and tried adding a warning to my local checkout.
Thanks for quickly checking this out.
Will be nice to get the API cleaned-up.
Leaving out part of the clean-up was a mistake.
Raymond
_
[Martin v. Löwis]
I disagree that our users are served by constantly breaking the
API, and removing stuff just because we can. I can't see how
removing API can possibly serve a user.
Am not following you here. My suggestion was to remove the two
methods in Py3.1 which isn't even in alpha yet.
Am not following you here. My suggestion was to remove the two
methods in Py3.1 which isn't even in alpha yet.
Your proposal was also to add a warning for 3.0.2. This is what I
primarily object to.
Okay, that's fine. Seemed prudent but it isn't essential.
This is for a feature
that has a
[Guido van Rossum]
Based on our experiences so far, I think that of the two options we
have, both of which are bad, it's better to keep things in 3.1 that we
were planning to remove but forgot, than to make 3.1 have a whole slew
of additional removals. We've removed cmp() in 3.0.1, and I think t
[MvL]
At this point, I do request that the patch is reverted completely
(i.e. that the documentation is restored), and that the qualification
"not reliable!" is removed from the doc strings of the methods, as
it is factually incorrect.
I would be happy to restore the documentation. You want t
[MvL]
At this point, I do request that the patch is reverted completely
(i.e. that the documentation is restored), and that the qualification
"not reliable!" is removed from the doc strings of the methods, as
it is factually incorrect.
I would be happy to restore the documentation. You want
[Benjamin Peterson]
On behalf of the Python development team and the Python community, I'm
happy to announce the first alpha release of Python 3.1.
Thanks for the good work.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
This is precisely the reason why I want Python to continue including its
batteries. If we give that up, it will not come back, and users get
frustrated that they have to collect stuff from many places, and that
the stuff doesn't fit together completely.
I concur.
Raymond
_
On behalf of the Python development team and the Python community, I'm
happy to announce the first alpha release of Python 3.1.
Are there any plans for a Windows installer?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
>>> You might also want to collect a list of serious changes that you
>>> want in this release;
Bob Ippolito has a good sized patch to update the json module
and improve its performance.
http://bugs.python.org/issue4136
Raymond
___
Python-Dev
You might also want to collect a list of serious changes that you
want in this release;
I'm making minor updates to the decimal module to match the 1.68 version of the
spec.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
I'm making minor updates to the decimal module to match the 1.68 version of the
spec.
Looks like most was already done. Just needs some doc fixes.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
[Nick Coghlan]
What about decimal-in-C, by the way? Is anyone still working on it?
I'm seeking funding for the project. If it is forthcoming, I intend to do
a pure C version that simply implements the spec and then adds
wrappers for the pure python interface. That will save the cost
of consta
201 - 300 of 1487 matches
Mail list logo
