We need a really long lead time before we can remove these. I
recommend starting with a *silent* deprecation in 3.1 combined with a
PR offensive for the new names.
I think the old names basically have to live forever in some way, due to
loading old pickles. Remember the problems we had when we
Antoine Pitrou wrote:
I think your "synced" flag is too vague. Some applications may need the file to
be synced on close(), but some others may need it to be synced at regular
intervals, or after each write(), etc.
Why wouldn't sync just be an optional argument to close(), at least for
the "sy
Antoine Pitrou wrote:
Eric Smith trueblade.com> writes:
Why wouldn't sync just be an optional argument to close(), at least for
the "sync_on_close" case?
It wouldn't work with the "with" statement.
Well, that is a good reason, then!
_
I'm implementing support for auto-numbering of str.format() fields (see
http://bugs.python.org/issue5237). I'm reasonably sure that when I'm
done modifying the C implementation I'll need to change the signatures
of string.Formatter._vformat, str._formatter_parser, and/or
str._formatter_field_na
Raymond Hettinger wrote:
Eric Smith pointed-out that these are already
handled by the "n" specifier in the locale module (albiet only
for integers).
It's supported by float, but it's just not very useful. For Decimal it's
unsupported. Maybe this isn't a
P.J. Eby wrote:
> As someone else suggested, moving some of the functionality to PEP 302
> interfaces would also help. Most of the code, though, deals with
> locating/inspecting installed distributions, resolving version
> requirements, and managing sys.path. And most of the nastiest
> complexit
anatoly techtonik wrote:
Correct me if I wrong, but shouldn't Python include function for
version comparisons?
What do you think about adding cmpversions(first, second,
strict=false) based on distutils into main lib?
distutils _is_ already in the "main lib", that is, the standard library.
M.-A. Lemburg wrote:
On 2009-03-27 04:19, Guido van Rossum wrote:
- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try to provide higher-level functionality in the stdlib, but
instead let third party tools built on top of these core APIs c
Olemis Lang wrote:
On Fri, Mar 27, 2009 at 5:22 AM, Paul Moore wrote:
2009/3/27 Guido van Rossum :
- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try to provide higher-level functionality in the stdlib, but
instead let third party tool
Martin v. Löwis wrote:
Correct me if I wrong, but shouldn't Python include function for
version comparisons?
On the packaging summit yesterday, people agreed that yes, we should
have something like that in the standard library, and it should be more
powerful than what distutils currently offers
Mart Sõmermaa wrote:
Instead of trying to parse some version string, distutils should
require defining the version as tuple with well-defined entries -
much like what we have in sys.version_info for Python.
The developer can then still use whatever string format s/he wants.
M.-A. Lemburg wrote:
On 2009-03-27 17:07, P.J. Eby wrote:
At 11:37 PM 3/26/2009 -0500, Eric Smith wrote:
P.J. Eby wrote:
As someone else suggested, moving some of the functionality to PEP 302
interfaces would also help. Most of the code, though, deals with
locating/inspecting installed
Olemis Lang wrote:
I also think the feature should go. If you want functionality that's so
difficult to provide when you install as a zip file, the answer is not to
make things more complex, but to not install as zip files.
What about environments like Google App Engine ? I mean, AFAIK using
Z
Martin v. Löwis wrote:
I got the impression that people are generally happy with what
setuptools provides for version parsing and comparison.
Does anyone think that's not a good model?
Procedurally, I think it's a very bad approach. I don't mind
the setuptools implementation being used as a
Martin v. Löwis wrote:
I do think that it's relevant that the respective operating system
packagers don't find bdist_rpm, bdist_deb, et. al. useful. It's not
very useful to have a bdist_deb that nobody actually builds debs with.
I think that conclusion is invalid: just because the distributi
Martin v. Löwis wrote:
I just collected the version strings of versions that
got released to PyPI, and put up the list on
http://www.dcl.hpi.uni-potsdam.de/home/loewis/versions
That's excellent, thank you.
The following chunk of text is present. I don't really care, except that
it might mean
Stephen J. Turnbull wrote:
Eric Smith writes:
> And I personally use bdist_rpm for my work, which I distribute to a farm
> of servers under my control. So no doubt it's used.
Sure, but use for internal distribution is very different from to
problem its being asked to solve no
Nick Coghlan wrote:
Csaba Balazs wrote:
Hello Everybody,
I would like to use a C++ gui library with the following (simplified) interface
in Python.
This is a question for python-list/comp.lang.python (i.e. development
*using* Python, including the C API), not python-dev (which is for
developm
Kristján Valur Jónsson wrote:
Btw, I am working on finding out the test suite failures for
test_multiprocessing.
Some of those are caused by force builds on a branch, so make sure the
errors are still occurring before you put too much effort into this. We
made the branch before some recent f
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Apr 6, 2009, at 9:21 AM, Jesse Noller wrote:
>
>> On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg wrote:
>>> On 2009-04-02 17:32, Martin v. Löwis wrote:
I propose the following PEP for inclusion to Python 3.1.
>>>
>>> Thanks for picking t
Mark Dickinson wrote:
One PyCon 2009 sprint later, Eric Smith and I have
produced the py3k-short-float-repr branch, which implements
short repr of floats and also does some major cleaning
up of the current float formatting functions.
We've gone for the {fast, correct} pairing.
We'd l
Assuming that Mark's and my changes in the py3k-short-float-repr branch
get checked in shortly, I'd like to deprecate PyOS_ascii_formatd. Its
functionality is largely being replaced by PyOS_double_to_string, which
we're introducing on our branch.
PyOS_ascii_formatd was introduced to fix the is
Nick Coghlan wrote:
Eric Smith wrote:
And as a reminder, the py3k-short-float-repr changes are on Rietveld at
http://codereview.appspot.com/33084/show. So far, no comments.
Looks like you were able to delete some fairly respectable chunks of
redundant code!
Wait until you see how much
Mark has uploaded our newest work to Rietveld, again at
http://codereview.appspot.com/33084/show. Since the last version, Mark
has added 387 support (and other fixes) and I've added localized
formatting ('n') back in as well as ',' formatting for float and int. I
think this addresses all open i
Benjamin Peterson wrote:
Cool. Will you use svnmerge.py to integrate the branch? After having
some odd behavior merging the io-c branch, suggest you just apply a
patch to the py3k branch,
We're just going to apply 2 patches, without using svnmerge. First we'll
add new files and the configure c
Ned Deily wrote:
In article <49e3d34e.8040...@trueblade.com>,
Eric Smith wrote:
Before then, if anyone could build and test the py3k-short-float-repr
branch on any of the following machines, that would be great:
[...]
Something bigendian, like a G4 Mac
I'll crank up some OS
Ned Deily wrote:
I'll crank up some OS X installer builds and run them on G3 and G4 Macs
vs 32-/64- Intel. Any tests of interest beyond the default regttest.py?
FIrst attempt was a fat (32-bit i386 and ppc) build on 10.5 targeted for
10.3 and above; this is the similar to recent python.org OS
Jess Austin wrote:
What other behavior options besides "last-valid-day-of-the-month"
would you like to see?
- Add 30 days to the source date.
I'm sure there are others.
Followups to python-ideas.
___
Python-Dev mailing list
Python-Dev@python.org
htt
Alessio Giovanni Baroni wrote:
There are some cases of OutOfMemory? On my machine the float->string
conversion is all ok. Also 'make test' is all ok.
I assume you're talking about issue 5775. I think it's all explained in
the bug report. Basically, the float->string conversion can now return
Eric Smith wrote:
Alessio Giovanni Baroni wrote:
There are some cases of OutOfMemory? On my machine the float->string
conversion is all ok. Also 'make test' is all ok.
I assume you're talking about issue 5775. I think it's all explained in
the bug report. Basic
Mark Dickinson wrote:
On Fri, Apr 24, 2009 at 9:25 PM, Terry Reedy wrote:
In going through this, I notice a lot of effort by Mark Dickenson and others
Many others, but Eric Smith's name needs to be in big lights here.
There's no way the short float repr would have been ready for 3.1 if
Eric h
Eric Smith wrote:
Assuming that Mark's and my changes in the py3k-short-float-repr branch
get checked in shortly, I'd like to deprecate PyOS_ascii_formatd. Its
functionality is largely being replaced by PyOS_double_to_string, which
we're introducing on our branch.
We've
Benjamin Peterson wrote:
2009/4/24 Eric Smith :
My proposal is to deprecate PyOS_ascii_formatd in 3.1 and remove it in
3.2.
Having heard no dissent, I'd like to go ahead and deprecate this API. What
are the mechanics of deprecating this? Just documentation, or is there
something I should
You might want to note in the PEP that the problem that's being solved
is known as the "loop and a half" problem.
http://www.cs.duke.edu/~ola/patterns/plopd/loops.html#loop-and-a-half
raymond.hettinger wrote:
Author: raymond.hettinger
Date: Sun Apr 26 02:34:36 2009
New Revision: 71946
Log:
Re
Mark Dickinson wrote:
I'd like to propose two minor changes to float and complex
formatting, for 3.1. I don't think either change should prove
particularly disruptive.
(1) Currently, '%f' formatting automatically changes to '%g' formatting for
numbers larger than 1e50. For example:
...
I pro
Mark Dickinson wrote:
(1) Currently, '%f' formatting automatically changes to '%g' formatting for
numbers larger than 1e50. For example:
'%f' % 2**166.
'93536104789177786765035829293842113257979682750464.00'
'%f' % 2**167.
'1.87072e+50'
I propose removing this feature for 3.1
I don't
Mark Dickinson pointed out to me that the trunk buildbots are failing
under Windows.
After some analysis, I think this is because of a change I made to use
_toupper in integer formatting. The correct solution to this is to
implement issue 5793 to come up with a working, cross-platform,
locale
> I couldn't figure out a way to get rid of it short of multi-#including
> "templates" and playing with the C preprocessor, however, and have the
> nagging feeling the latter would be frowned upon by the maintainers.
Not sure if this is exactly what you mean, but look at Objects/stringlib.
str.for
Michael Foord wrote:
Larry Hastings wrote:
I've written a patch for Python 3.1 that changes os.path so it handles
UNC paths on Windows:
http://bugs.python.org/issue5799
+1 for the feature. I have to deal with Windows networks from time to
time and this would be useful.
+1 from me, too
When checking in, I get:
Transmitting file data .svn: Commit failed (details follow):
svn: Can't create directory
'/data/repos/projects/db/transactions/72186-1.txn': Read-only file system
With 'svn up', I get:
svn: Can't find a temporary directory: Internal error
In issue 5920, Mark Dickinson raises an issue having to do with
float.__format__ and how it handles the default format presentation type
(that is, none of 'f', 'g', or 'e') versus how str() works on floats:
http://bugs.python.org/issue5920
I agree with him that the current behavior is confusin
Mark Hammond wrote:
Is that enough consensus for it to go in? If so, are there any core
developers who could help me get it in before the 3.1 feature freeze?
The patch should be in good shape; it has unit tests and updated
documentation.
I've taken the liberty of explicitly CCing Martin jus
Modules/posixmodule.c now compiles for me, but I get a Bus Error in
test_lchflags when running test_posixmodule on Mac OS X 10.5. I'll open
a release blocker bug on this.
Original Message
Subject: [Python-checkins] r72331 -
python/branches/py3k/Modules/posixmodule.c
Date: Tu
Neal Becker wrote:
"format_spec ::= [[fill]align][sign][#][0][width][.precision][type]"
"The precision is ignored for integer values."
In [36]: '%3x' % 10
Out[36]: ' a'
In [37]: '%.3x' % 10
Out[37]: '00a'
Apparently, precision is _not_ ignored?
That section is talking about this:
>>> for
Eric Smith wrote:
Neal Becker wrote:
"format_spec ::= [[fill]align][sign][#][0][width][.precision][type]"
"The precision is ignored for integer values."
In [36]: '%3x' % 10
Out[36]: ' a'
In [37]: '%.3x' % 10
Out[37]: '00a'
Appare
Tarek:
With you ARFLAGS change, I now get the following error on a 32 bit
Fedora 6 box. I've done "make distclean" and "./configure":
$ make
...
gcc -pthread -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I.
-IInclude -I./Include -DPy_BUILD_CORE -I./Modules/_io -c
./Modules/_io/texti
Tarek Ziadé wrote:
On Thu, May 7, 2009 at 11:36 PM, Eric Smith wrote:
With you ARFLAGS change, I now get the following error on a 32 bit Fedora 6
box. I've done "make distclean" and "./configure":
Sorry yes, I am on it now, the produced Makefile is broken, unt
Tarek Ziadé wrote:
I have fixed configure by runing autoconf, everything should be fine now
And indeed, it's working fine now, thanks.
Sorry for the inconvenience.
Not a problem. Anyone who volunteers for autoconf work gets a free pass
from me.
Eric.
Antoine Pitrou wrote:
Yes, I realized that's one of the problems with this proposal. If we had to
maintain more than one stable branch, it would become a burden.
Agreed. And since we have 2.x and 3.x now, we already have that problem.
I'd like to an acceleration of release schedules (if it eve
raymond.hettinger wrote:
Author: raymond.hettinger
Date: Fri May 29 00:20:03 2009
New Revision: 72995
Log:
Deprecate contextlib.nested(). The with-statement now provides this
functionality directly.
Modified:
python/branches/py3k/Doc/library/contextlib.rst
python/branches/py3k/Doc/whats
I'm against syntax for this, for all the reasons stated by others.
Jerry Chen wrote:
Just one last note: I think my end goal here was to preserve the
visual clarity and separation between format string and format
parameters, as I much prefer:
"%s %s %s" % (1, 2, 3)
over
"{0} {1} {2}".format(1
Antoine Pitrou wrote:
Paul Moore gmail.com> writes:
I have no answer here. But I think we need feedback from the people
who will ultimately be building bdist_xxx formats - Debian packagers,
people wrting alternate RPM builders, etc.
I think any bdist_xxx command which targets externally handl
P.J. Eby wrote:
At 08:59 AM 7/8/2009 -0400, Eric Smith wrote:
I agree with this. For RPM's, there's a whole other database of what
files were installed. Is it really the intent that a file will be
managed by multiple different installers? That I can install with RPM
but remove
Paul Moore wrote:
2009/7/8 P.J. Eby :
If it were being driven by setuptools, I'd have just implemented it myself
and presented it as a fait accompli. I can't speak to Tarek's motives, but
I assume that, as stated in the PEP, the primary driver is supporting the
distutils being able to uninstall
Stephen J. Turnbull wrote:
Eric Smith writes:
> But I think we've veered into metadata that describes what has been
> installed. I don't think that's so useful. As I've said, this is private
> to the installers. If 2 installers want to communicate with each
Steven D'Aprano wrote:
On Thu, 9 Jul 2009 08:07:21 am Eric Smith wrote:
But I think we've veered into metadata that describes what has been
installed. I don't think that's so useful. As I've said, this is
private to the installers. If 2 installers want to communicate w
P.J. Eby wrote:
ISTM that the problem that it solves is uninstall in the absence of
the original installer.
Or uninstall where the installer is "setup.py install", actually.
I think we need to move away from "setup.py install". It's the
antithesis of static metadata. setup.py needs to go awa
Eventually, I'd like PEP 376 to support system packagers too. So for
example, if you did "apt-get install python-pyqt4", then running "pip
install python-pyqt4" should return without installing anything .. as
RECORD will be part of the .deb previously installed. As for generating
the RECORD fil
P.J. Eby wrote:
At 11:20 PM 7/8/2009 -0400, Eric Smith wrote:
P.J. Eby wrote:
ISTM that the problem that it solves is uninstall in the absence of
the original installer.
Or uninstall where the installer is "setup.py install", actually.
I think we need to move away from "s
Benjamin Peterson wrote:
Then, you might garner some more reviews by putting your patch up on
Rietveld; it makes reviewing much painful.
"... much _less_ painful", I hope!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailm
Peter Moody wrote:
On Wed, Aug 19, 2009 at 3:20 AM, Antoine Pitrou wrote:
Le Tue, 18 Aug 2009 13:00:06 -0700, Peter Moody a écrit :
Howdy folks,
I have a first draft of a PEP for including an IP address manipulation
library in the python stdlib. It seems like there are a lot of really
smart fo
Peter Moody wrote:
On Wed, Aug 19, 2009 at 9:21 AM, R. David Murray wrote:
Possibly. Tino means exactly what he said: the broadcast address
does not _have_ to be the last IP, nor does the last IP _have_ to be
a broadcast, though in practice they almost always are (and using the
last IP as a
Glyph Lefkowitz wrote:
On Wed, Aug 19, 2009 at 2:20 PM, Eric Smith <mailto:e...@trueblade.com>> wrote:
I think using .network and .broadcast are pretty well understood to
be the [0] and [-1] of the network address block. I don't think we
want to start creating new t
[Glyph]
So it sounds like doing what I suggested earlier (default to [-1], allow
for customization) is actually required by the RFC :-). Although it
does sound like the RFC only requires that you be able to customize to
[0] rather than [-1], rather than any address. In practical terms
though
Fred Drake wrote:
On Aug 19, 2009, at 6:01 PM, Peter Moody wrote:
just to double check, it's fine for IPNetwork to remain hashable if
set_prefix() actually returned a new object, correct?
The name would be confusing, though. Perhaps using_prefix() would be
more clear.
I think you'd be bet
Erik Bray wrote:
I think Guido may have a point about not allowing any arbitrary
expression. But I do think that if it allows calls, it should also at
least support the itemgetter syntax, for which there seems to be a
demonstrable use case. But that's just adding on another special
case, so it
The default string formatting alignment for all types, according to PEP
3101, is left aligned. Issue 6857 (http://bugs.python.org/issue6857)
points out that for numeric types (int, float, and decimal, at least),
the actual implemented default alignment is right aligned.
Mark Dickinson and I ag
Greg Ewing wrote:
Is the new formatting supposed to behave the same way
as %-formatting for the same format codes? Because the
default for %-formatting is actually right alignment
for *all* types, including strings.
Hmm, I never noticed that. At this point, I think changing the
formatting for
Mark Dickinson wrote:
On Mon, Sep 7, 2009 at 11:10 PM, Eric Smith wrote:
Hmm, I never noticed that. At this point, I think changing the formatting
for any types would break code, so we should just change the documentation
to reflect how currently works.
I think the alignment for Decimal *does
> Mark Dickinson wrote:
>> I think the alignment for Decimal *does* need to be changed, though. It
>> currently left-aligns by default (my fault: I just blindly followed PEP
>> 3101
>> without thinking too hard about it). I'd like to fix this for 3.2 and
>> 2.7; I'm
>> not sure whether it's too
Antoine Pitrou wrote:
Peter Moody hda3.com> writes:
However, I do not think
that the proposed API should accept, eg, IPv4Network('192.168.1.1/24')
as valid. That's just too confusing and error prone.
Indeed, it should throw some kind of ValueError instead.
Peter, what do you think?
I disagr
Antoine Pitrou wrote:
Antoine Pitrou pitrou.net> writes:
I don't see any valid reason for entering a network as "192.168.1.1/24" rather
than the canonical "192.168.1.0/24". The former might indicate a typing error
or
a mental slip, so let's be helpful and signal it to the user.
Or perhaps the
A.M. Kuchling wrote:
We therefore need to decide what those three sessions should be about.
Please discuss on python-dev and hopefully we can arrive at some
consensus on topics of reasonably wide current interest. (See
http://us.pycon.org/2009/about/summits/language/ for a reminder of
last year'
Eric.
"Greg Ewing" wrote:
>Nick Coghlan wrote:
>
>> Or, to put it another way, given an arbitrary host in a network (e.g.
>> your own machine or the default gateway) and the netmask for that
>> network, calculate the network address.
>
>Some people have claimed that the gateway address of a
>ne
Antoine Pitrou wrote:
Le Thu, 17 Sep 2009 14:30:28 +1200, Greg Ewing a écrit :
3) an Address with an attached Network
An Address could be constructed in three ways:
Address(ip_number)
Address(ip_number, network = )
Address(ip_number, mask = )
# constructs and attaches a suitabl
Nick Coghlan wrote:
Eric Smith wrote:
Antoine Pitrou wrote:
As it is, -1 from me. Either we only keep two concepts (Address and
Network), or if we introduce a third one (AddressWithMask,
whatever) for added practicality; but we shouldn't blur the line
between the two former canonical con
Nick Coghlan wrote:
To be honest, given the indexing behaviour, I'm -1 on the idea of giving
the network address or broadcast address attribute names *at all*. Consider:
network_address = my_net[0]
broadcast_address = my_net[-1]
My only concern with this is a possible performance issue wit
Peter Moody wrote:
indexing is plenty efficient, but the problem is that these names for
these attributes are common to the point of causing confusion if
they're omitted.
After thinking about it some more, I'm okay with names for [-1] and [0].
I like .broadcast, and I can live with .network (
R. David Murray wrote:
On Thu, 17 Sep 2009 at 10:57, Brett Cannon wrote:
Looks great to me! Only thing missing that I can think of is sticking
Eric down as the guy who does str.format(). =)
OK, I've added that one to the last table ;)
Awesome! I get to spend even more time on formatting stri
Cameron Simpson wrote:
On 18Sep2009 07:48, Nick Coghlan wrote:
| Eric Smith wrote:
| > Peter Moody wrote:
| >> indexing is plenty efficient, but the problem is that these names for
| >> these attributes are common to the point of causing confusion if
| >> they'
s...@pobox.com wrote:
Dino> For IronPython we wrote a set of tests which go through and define
Dino> the various operator methods in all sorts of combinations on both
Dino> new-style and old-style classes as well as subclasses of those
Dino> classes and then do the comparisons w/
Michael Foord wrote:
Benjamin Peterson wrote:
2009/9/23 Michael Foord :
Benjamin Peterson wrote:
2009/9/23 Michael Foord :
Isn't that the real compatibility test *anyway* - how successful a new
version of Python is at running all the existing Python code...
Yes, but we
R. David Murray wrote:
The fundamental divide here is between two behaviors.
ipaddr:
>>> x = IPv4Network('192.168.1.1/24')
>>> y = IPv4Network('192.168.1.0/24')
>>> x == y
False
>>> x.ip
IPv4Address('192.168.1.1')
desired:
>>> x = IPv4Network('192.168.1.1/24')
Mark Dickinson wrote:
On Mon, Sep 28, 2009 at 3:04 PM, Daniel Stutzbach
wrote:
On Mon, Sep 28, 2009 at 7:24 AM, Nick Coghlan wrote:
I should note that I've softened my position slightly from what I posted
yesterday. I could live with the following compromise:
>>> x = IPv4Network('192.168.
Paul Moore wrote:
2009/9/28 Yuvgoog Greenle :
1. There is no chance of the script killing itself. In argparse and optparse
exit() is called on every parsing error (btw because of this it sucks to
debug parse_args in an interpreter).
That one does worry me. I'd rather argparse (or any library f
Martin v. Löwis wrote:
Steven Bethard wrote:
There's a lot of code already out there (in the standard library and
other places) that uses %-style formatting, when in Python 3.0 we
should be encouraging {}-style formatting.
I don't agree that we should do that. I see nothing wrong with using
%
Vinay Sajip wrote:
Good point as far as the general case is concerned, though it's perhaps not that
critical for logging. By which I mean, it's not unreasonable for
Formatter.__init__ to grow a "style" keyword parameter which determines whether
it uses %-, {}- or $-formatting. Then the formatter
Antoine Pitrou wrote:
Vinay Sajip yahoo.co.uk> writes:
"%0#8x" % 0x1234
'0x001234'
"{0:0>#8x}".format(0x1234)
'000x1234'
Apart from the sheer unreadability of the {}-style format string, the result
looks rather unexpected from a human being's point of view.
(in those situations, I would
Vinay Sajip wrote:
BTW I sent Eric a private mail re. the "0o" versus "0" issue, to see if it was
worth raising an enhancement request on the bug tracker using "O" to generate
compatible rendering for octals.
I didn't get your message, could you resend?.
I was thinking the same thing, but it s
Christian Tanzer wrote:
Eric Smith wrote at Thu, 08 Oct 2009 10:24:33 -0400:
Vinay Sajip wrote:
BTW I sent Eric a private mail re. the "0o" versus "0" issue, to see if it was
worth raising an enhancement request on the bug tracker using "O" to generate
compa
Benjamin Peterson wrote:
2009/10/8 Eric Smith :
Christian Tanzer wrote:
IMHO, either the translation is done once and gives identical output or
it isn't worth doing at all.
I disagree. I doubt even 0.001% of all format strings involve octal
formatting. Is it really worth not provid
Nick Coghlan wrote:
Benjamin Peterson wrote:
2009/10/8 Eric Smith :
Christian Tanzer wrote:
IMHO, either the translation is done once and gives identical output or
it isn't worth doing at all.
I disagree. I doubt even 0.001% of all format strings involve octal
formatting. Is it really
Vinay Sajip wrote:
If __builtins__ is an implementation detail which can't be relied on, should the
py3k code be changed to the try: form? Or shall I just remove the checks
altogether, since Unicode should always be there in 3.x?
Remember that the identifier "unicode" isn't present in py3k. The
Glyph Lefkowitz wrote:
I'd much rather have my doctests and float-repr'ing code break on 2.7 so
I can deal with it as part of a minor-version upgrade than have it break
on 3.x and have to deal with this at the same time as the unicode->str
explosion. It feels like a backport of this behavior
[Tim:]
> If you don't consider Windows to be a major platform ;-) Besides that
> there's just no guessing what the Microsoft double->string routines
> will produce for the 17th digit, the MS routines always produce 3
> digits for the exponent in scientific notation, while AFAIK all other
> platfor
s...@pobox.com wrote:
I notice that WITHOUT_COMPLEX still appears in Python.h and several .c files
but nowhere else in the 2.6, 2.7 or 3.1 source, most particularly not in
configure or pyconfig.h.in. Are builds --without-complex still supported?
Has it been tested at any time in the recent past?
s...@pobox.com wrote:
Eric> I haven't tested it, but I still see WITHOUT_COMPLEX in trunk and py3k
Eric> branches. In py3k, it's referenced in:
...
Sure, but is it ever exercised? A name like WITHOUT_COMPLEX suggests that
it should be flipped on/off by configure using --without-com
> On Tue, Oct 20, 2009 at 11:49 AM, Nick Coghlan wrote:
>> Mark Dickinson wrote:
>>> This high-precision inefficiency could easily be fixed by
>>> using a dedicated 'decimal natural number' extension
>>> type for the Decimal coefficient, stored internally in base
>>> a suitable power of 10. [...]
Antoine Pitrou wrote:
Adam Olsen gmail.com> writes:
Looks like an OS bug to me. Linux I'm guessing?
Yes, but only on certain boxes. I could never reproduce on my home box.
RDM (David)'s buildbot is a Gentoo vserver with a reiserfs filesystem.
You'll occasionally see something similar on Wi
s...@pobox.com wrote:
mal> I don't think users will really go for carrots. Python 2.x is
mal> mature enough already and at least the users I know are really
mal> happy with it (including myself).
Taking that thought further back one step (or three), from
http://effbot.org/tkinte
1 - 100 of 347 matches
Mail list logo
