Stefan Krah wrote:
Hi,
I think http://www.python.org/dev/peps/pep-3101/ is too liberal with the
choice of fill characters for numerical values. As far as I can see, this
is quite legal:
Python 2.7a0 (trunk:76132M, Nov 6 2009, 15:20:35)
[GCC 4.1.3 20080623 (prerelease) (Ubuntu 4.1.2-23ubuntu3
Stefan Krah wrote:
Eric Smith wrote:
Stefan Krah wrote:
Hi,
I think http://www.python.org/dev/peps/pep-3101/ is too liberal with the
choice of fill characters for numerical values. As far as I can see, this
is quite legal:
Python 2.7a0 (trunk:76132M, Nov 6 2009, 15:20:35)
[GCC 4.1.3
Tarek Ziadé wrote:
I was wondering what's the status of PEP 382. Is anyone (MvL?) is
going to start to work on its implementation for Python 2.7/3.2
inclusion ?
If Martin isn't interested in doing it, I'll take a try at it. But I'll
need some rough guidance on the implementation approach.
Er
M.-A. Lemburg wrote:
Since package developers are just starting to port things to 3.x and
many appear to be considering supporting both 2.7 and 3.1 (including
myself), I find it a bit strange that such an import aliasing header
was removed in 3.1.
There's some discussion of this at http://bugs.
While researching http://bugs.python.org/issue7327, I've come to the
conclusion that trunk handles locales incorrectly in regards to Unicode.
Fixing this would be the first step toward resolving this issue with
float and Decimal locale-aware formatting.
The issue concerns the locale "cs_CZ.UTF-
Mark Dickinson wrote:
I find it odd that, for float formatting, the choice of fill character
affects whether commas are inserted:
Python 3.2a0 (py3k:76671, Dec 4 2009, 18:55:54)
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more infor
Tarek Ziadé wrote:
Also, the word "rational" is not familiar to me in the context of versions;
is this term known outside of this proposal? I couldn't find any reference
to it.
Do you have a better suggestion ? I was thinking about StandardVersion
but "Standard"
doesn't really express what we w
Tarek Ziadé wrote:
On Sat, Dec 12, 2009 at 10:35 PM, Brett Cannon wrote:
[...]
'nt': {
'stdlib': '$base/Lib',
'platstdlib': '$base/Lib',
'purelib': '$base/Lib/site-packages',
'platlib': '$base/Lib/site-packages',
'include': '$base/include',
'platinclud
>> Shouldn't this encoding guessing be a separate function that you call
>> on either a file or a seekable stream ?
>>
>> After all, detecting encodings is just as useful to have for non-file
>> streams.
>
> Other stream sources typically have out-of-band ways to signal the
> encoding: only when r
This discussion probably belongs on the distutils list.
Ron Adam wrote:
Can I make my efforts in developing a (module, package, script, or
application) a lot easier if I keep certain things in mind? Are there
any best practices I should keep in mind if I intend to distribute my work?
Are ther
Mark Dickinson wrote:
What are the current plans for PEP 328 (the absolute imports PEP) in Python 2.x?
The PEP says:
"""In Python 2.6, any import statement that results in an
intra-package import will raise DeprecationWarning (this also applies
to from <> import that fails to use the relative i
Mark Dickinson wrote:
On Tue, Feb 2, 2010 at 1:20 PM, Eric Smith wrote:
Mark Dickinson wrote:
What are the current plans for PEP 328 (the absolute imports PEP) in
Python 2.x?
Not sure about the decision one way or the other. But if there's not going
to be a 2.8, and if DeprecationWar
Glenn Linderman wrote:
On approximately 1/30/2010 4:00 PM, came the following characters from
the keyboard of Barry Warsaw:
When the Python executable is given a `-R` flag, or the environment
variable `$PYTHONPYR` is set, then Python will create a `foo.pyr`
directory and write a `pyc` file to th
Sjoerd Mullender wrote:
On 2010-02-19 14:10, Guido van Rossum wrote:
Isn't mhlib itself deprecated? (It's gone in Py3k.)
I wouldn't like that, but it is beside my point. If a module is
deprecated, then it should not be used in released code.
If mhlib is deprecated, it doesn't tell you about i
Glenn Linderman wrote:
On approximately 2/19/2010 1:18 PM, came the following characters from
the keyboard of P.J. Eby:
At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote:
I'm not sure how this should best work on Windows (without symlinks,
and where things generally work differently), but I would
Glenn Linderman wrote:
Shortcuts don't work from the shell (well, cmd.exe, at least), do
they? Can't test from here.
So if you can't test it, why would you state it as a fact... and then
back-pedal? :)
It was a question, not a statement! Plus, I figured I could con someone
into testing it
Christian Heimes wrote:
As long as Python supports XP we shouldn't use symlinks on Windows for
stuff like virtualenv. The python.exe on Windows is small (just a few
kb) since it is linked against the dll. Let's copy it and we are on the
safe side.
+1. Even if we dropped XP I'm not sure moving
Steven Bethard wrote:
On Fri, Feb 19, 2010 at 7:50 AM, Brett Cannon wrote:
My notes from the session I led:
+ argparse
- Same issues brought up.
For those of us not at PyCon, what were the issues?
I think they were all related to deprecation of optparse, not anything
to do with argpar
Brett Cannon wrote:
Yes, DeprecationWarning is now silent under Python 2.7 and 3.1 so a
DeprecationWarning would only pop up if developers exposed
DeprecationWarning. But if the module is not about to be removed in 3.x
then I think regardless of the silence of both warnings it should stay
Pend
This code works on 2.6 and 3.0:
>>> format(1+1j, '10s')
'(1+1j)'
That's because format ends up calling object.__format__ because complex
doesn't have its own __format__. Then object.__format__ calls str(self)
which returns '(1+1j)'. So the original call basically turns into
"format('(1
Eric Smith wrote:
This code works on 2.6 and 3.0:
>>> format(1+1j, '10s')
'(1+1j)'
That's because format ends up calling object.__format__ because complex
doesn't have its own __format__. Then object.__format__ calls str(self)
which returns '
The root cause of this problem is object.__format__, which is basically:
def __format__(self, fmt):
return str(self).__format__(fmt)
So here we're changing the type of the object (to str) but still keeping
the same format string. That doesn't make any sense: the format string
is type specifi
http://bugs.python.org/issue7094 proposes adding "alternate" formatting
[1] to floating point new-style formatting (float.__format__ and
probably Decimal.__format__). I'd like to add this to make automated
translation from %-formatting strings to str.format strings easier.
Would this be allowe
Are the diffs gone for some deliberate reason?
I realize the link tells me the changes, but I'll review a lot more code
if the diffs show up in my inbox than if I have to fire up a browser,
especially from my phone.
Eric.
Brett Cannon wrote:
1) I miss not having the affected files listed in
Nick Coghlan wrote:
Greg Ewing wrote:
Steven Bethard wrote:
Because the names are so long and you'd have to import them, I've left
them as private attributes of the module, but if there's really
demand, we could rename them to argparse.StoreTrueAction, etc.
What's wrong with just StoreTrue?
Can you create an issue on the bug tracker? Otherwise this will get lost.
Eric.
On 3/13/2010 12:24 PM, gregory dudek wrote:
The Telnet module telnetlib.py can be
very slow -- unusably slow -- for large automated data transfers. There are
typically done in raw mode.
The attached patch greatly
Sean Reifschneider wrote:
If you call:
from syslog import syslog, openlog
syslog('My error message')
Something like the following gets logged:
Mar 18 05:20:22 guin python: My error message
^^
Where I'm annoyed by the "python" in the above. This is pulled
Brian Curtin wrote:
Hi all,
Having been active in bug triage and patch writing/reviewing since late
2009, it was suggested in the python-dev IRC channel that I request
commit access to the repository. I'm primarily a Windows user and have
worked with many of the other active contributors to d
Filip Gruszczyński wrote:
From that spec, a straightforward API falls out:
def format_mapping(self, kwds):
# Method body actually written in C, so it can
# easily invoke the internal formatting operation
return do_string_format(self, NULL, kwds)
Thanks a lot for the advice, I
Nick Coghlan wrote:
Filip Gruszczyński wrote:
I would appreciate any advice on this topic, even if this ticket would
be dismissed altogether, as I would like to learn as much as possible
on practices on developing Python.
Raymond's use case is valid, but the currently proposed method name is
w
Nick Coghlan wrote:
Moving the decision of "how am I going to be called" to the time of
writing the format string is a bit odd.
On the other hand, the specially crafted format string does have the
virtue of travelling far more easily through any APIs that wrap the
basic format() method (since it
Nick Coghlan wrote:
Completely agree on all points. Now we're just left with "is it worth
expanding the str api for this?". I don't feel strongly either way.
For something as core as the string API, we better feel darn strongly
about it before we mess with it :)
I'm inclined to leave it alone
In my case it was not a waste of time. I use MSDN for dev and testing. Just not
for release building.
"Steve Holden" wrote:
>Paul Moore wrote:
>> On 14 April 2010 07:37, Paul Rudin wrote:
>>> "Martin v. Löwis" writes:
>>>
The major difference in the "do it yourself" attitude is that Mac
Andrew MacIntyre wrote:
It is nice to get
heads-up messages about issues that might involve such support though,
and it shouldn't take much searching to find me to enquire.
Especially since aimacintyre is listed in Misc/maintainers.rst.
___
Python-D
Steven Bethard wrote:
By the way, we could simplify the typical add_argument usage by adding
"show program's version number and exit" as the default help for the
'version' action. Then you should just write:
parser.add_argument('--version', action='version', version='')
I like this the bes
Cameron Simpson wrote:
On 20Apr2010 15:27, Neal Becker wrote:
| Steven Bethard wrote:
|
| > On Tue, Apr 20, 2010 at 11:55 AM, Neal Becker wrote:
| >> I've noticed argparse ambiguity handling has changed a bit over last few
| >> revisions.
| >>
| >> I have cases where 1 valid input is a prefix
Jeroen Ruigrok van der Werven wrote:
-On [20100422 10:55], Tarek Ziadé (ziade.ta...@gmail.com) wrote:
The next big piece is the FHS-compatible handling of resource files,
which will worth a PEP on its own.
You do realize, I hope, that FHS is only followed by Linux distributions and
not even fu
Sounds good to me (subject to arguing about spellings, case
insensitivity, etc.). Just so it doesn't get lost, I created issue 8538
to track it.
Neal Becker wrote:
steven.beth...@gmail.com made a very nice module for me to enhance argparse
called argparse_bool.py, which contains ConfigureActio
ike (in the last hour) Jesus Crea
> (#8536), Eric Smith (*8538), and Mark Dickenson (*8540).
You neglected my 2 dupes at 8537 and 8539! :)
> If possible, I think 'normal' should be the default in the hox or else
> there shoul
Martin v. Löwis wrote:
If possible, I think 'normal' should be the default in the hox or else
there should be some sort of auto replacement.
Makes sense to me.
I have now changed to make 'normal' the default priority for new issues.
Shall I also set the priority on all past issues to normal wh
Dirkjan Ochtman wrote:
On Tue, May 4, 2010 at 14:41, Antoine Pitrou wrote:
I think we should reindent all 3 branches. Most of the work can probably be
scripted (str.replace("\t", " " * 4)), and then a visual pass is necessary to
fix vertical alignments and the like.
If the script is robust en
It looks like we're moving ahead with removing tabs. Was there consensus
on this?
Last I saw Antoine had written a script that might do what we want, but
hadn't been thoroughly tested. Now I've seen a few checkins for files
that have been run through the script.
What gives? And why do this s
Antoine Pitrou wrote:
Eric Smith trueblade.com> writes:
Last I saw Antoine had written a script that might do what we want, but
hadn't been thoroughly tested. Now I've seen a few checkins for files
that have been run through the script.
As far as I'm concerned, it was a
Brett Cannon wrote:
In the end it's Benjamin's call, but my vote is to make the change.
The chances someone wanted None as their help message is so bloody
small and this is such a good UX change that I'm +1 on making the
change.
I completely agree.
--
Eric.
___
Steven D'Aprano wrote:
I have suggested a way to move the existing concurrency stuff without
breaking backwards compatibility, and Terry Reedy asked if it would
work. I haven't seen any responses, either positive or negative.
For the record, my suggestion was:
for each concurrency modules:
Last night Barry Warsaw, Jason Coombs, and I met to work on implementing
PEP 382. As part of my research, I came across this email from Martin:
http://mail.python.org/pipermail/python-dev/2009-May/089316.html
In it he says that PEP 382 is being deferred until it can address PEP
302 loaders. I c
> On 6/9/2010 4:07 AM, Stephen J. Turnbull wrote:
> Closed issues are not lost. They can still be searched and the result
> downloaded.
>
>> A keyword would do. Please don't add a status or something like that,
>> though.
>
> I believe Type: feature request; Version: 2.7; Resolution wont fix
> sho
On 6/27/2010 5:48 AM, Greg Ewing wrote:
Stefan Behnel wrote:
Greg Ewing, 26.06.2010 09:58:
Would there be any sanity in having an option to compile
Python with UTF-8 as the internal string representation?
It would break Py_UNICODE, because the internal size of a unicode
character would no lo
On 7/9/10 10:40 AM, Mark Dickinson wrote:
While looking at a parser module issue
(http://bugs.python.org/issue9154) I noticed that Python's grammar
doesn't permit trailing commas after keyword-only args. That is,
def f(a, b,): pass
is valid syntax, while
def f(*, a, b,): pass
is n
On 7/9/2010 4:42 PM, Georg Brandl wrote:
Am 09.07.2010 22:26, schrieb Mark Dickinson:
On Fri, Jul 9, 2010 at 8:37 PM, Dino Viehland wrote:
Terry wrote:
This violates the important principle that allowed def and call arg
sequences should match to the extent sensible and possible. In this
sense
On 7/11/2010 5:19 AM, anatoly techtonik wrote:
On Fri, Jul 9, 2010 at 6:59 PM, Jeffrey Yasskin wrote:
While the re2 comparison might be interesting from an abstract
standpoint, it intentionally supports a different regex language from
Python so that it can run faster and use less memory. Since
On 7/12/2010 5:57 PM, Benjamin Peterson wrote:
2010/7/12 "Martin v. Löwis":
Not normally, no - there's no easy way to connect a checkin message to
a committer's email address,
There's a one-to-one mapping somewhere.
Unfortunately, no: we don't have email addresses of all committers.
What a
On 7/12/2010 6:04 PM, Michael Foord wrote:
Given how high traffic python-checkins is I don't consider that a
reasonable place to send follow-up and nor do I consider it the
responsibility of committers to monitor it. As you said earlier this
*isn't* in our standard dev procedures and nor do I thi
On 7/14/2010 4:21 AM, Georg Brandl wrote:
Am 13.07.2010 22:29, schrieb Brett Cannon:
Given how high traffic python-checkins is I don't consider that a
reasonable place to send follow-up and nor do I consider it the
responsibility of committers to monitor i
Thanks for writing this, Tim.
On 7/21/10 11:11 AM, Tim Golden wrote:
The issue of a __format__ equivalent for bytes was also raised as was the
idea of object methods to render an object as string or bytes, which could
be used in the polymorphic functions above.
Does this mean bytes.__format__
On 7/23/10 2:44 AM, Guido van Rossum wrote:
Indeed, we meant b'...{}...{}...'.format(x, y). The problem is that it
can't invoke x.__format__() or y.__format__() since those will return
text strings instead of bytes. A proposed solution was to try
x.__bformat__() etc. Another proposed solution was
On 7/27/10 2:31 PM, Terry Reedy wrote:
On 7/27/2010 1:48 PM, Alexander Belopolsky wrote:
Multicolored diffs may look impressive the first time you see them,
Side-by-side was the important part
> Copying code
from side by side view may or may not work depending on your browser.
It is a nu
> On Tue, Jul 27, 2010 at 2:48 PM, Eric Smith wrote:
> ..
>> I agree with Terry that this would be a useful feature to have
>> integrated
>> with the tracker. I'd use it. But until someone write it, it's an
>> academic
>> point.
>
> I don&
On 8/4/2010 6:09 PM, Nick Coghlan wrote:
On Thu, Aug 5, 2010 at 8:02 AM, Fred Drake wrote:
On Wed, Aug 4, 2010 at 5:57 PM, Nick Coghlan wrote:
and use a default message of
"'Key not found: %r' % key" if the key argument is supplied without an
explicit message
I suspect you meant a default m
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
1 - 100 of 347 matches
Mail list logo
