Thomas Wouters wrote:
Unfortunately, that's not how it works :-) If you check something into
the trunk, it will be merged into Py3k sooner or later. I may ask the
original submitter for assistance if it's incredibly hard to figure out
the changes, but so far, I only had to do that with the
Fred Drake wrote:
On Oct 24, 2007, at 4:23 PM, Facundo Batista wrote:
There (and always talking in windows), the OP says the in Py2.4
os.path.exists(nul) returned True and now in 2.5 returns False. Note
that nul is an special file, something like /dev/null.
It's special, but in a different
(I'm posting to python-dev, because this isn't strictly 3.0 related.
Hopefully most people read it in addition to python-3000).
I'm working on backporting the changes I made for PEP 3101 (Advanced
String Formatting) to the trunk, in order to meet the pre-PyCon release
date for 2.6a1.
I have a
M.-A. Lemburg wrote:
On 2008-01-10 14:31, Eric Smith wrote:
(I'm posting to python-dev, because this isn't strictly 3.0 related.
Hopefully most people read it in addition to python-3000).
I'm working on backporting the changes I made for PEP 3101 (Advanced
String Formatting) to the trunk
Nick Coghlan wrote:
Guido van Rossum wrote:
For data types whose output uses only ASCII, would it be acceptable if
they always returned an 8-bit string and left it up to the caller to
convert it to Unicode? This would apply to all numeric types. (The
date/time types have a strftime() style
Steve Holden wrote:
Nick Coghlan wrote:
To elaborate on this a bit (and handwaving a lot of important details
out of the way) do you mean something like the following for the builtin
format?:
def format(obj, fmt_spec=None):
if fmt_spec is None: fmt_spec=''
result =
[EMAIL PROTECTED] wrote:
discussion of per-user directories on different platforms
One of the problems we've encountered over and over again with
Combinator is that MacOS has a dual personality. Its personality is not
just an issue of framework vs. non-framework build, but a fundamental
In 3.0, the code to implement long.__format__() calls PyNumber_ToBase to
do the heavy lifting. If someone is planning on implementing
PyNumber_ToBase in 2.6, I'll wait for them to do so. If not, I guess
I'll either do it myself, or hack around it.
Is this on anyone's To Do list? I don't see
Guido van Rossum wrote:
On Jan 23, 2008 7:40 AM, Eric Smith [EMAIL PROTECTED] wrote:
In 3.0, the code to implement long.__format__() calls PyNumber_ToBase to
do the heavy lifting. If someone is planning on implementing
PyNumber_ToBase in 2.6, I'll wait for them to do so. If not, I guess
Guido van Rossum wrote:
On Jan 27, 2008 9:26 AM, Andrea Griffini [EMAIL PROTECTED] wrote:
Anyway I want just to say that if implicit conversion from float
to integer goes away then what happens to formatting conversion ?
Removing that too IMO would break a lot of code and it's IMO very
Raymond Hettinger wrote:
[GvR]
I don't see why. __index__ has a slot because its
primary use is to be called from C code, where slots
add a slight performance advantage.
__trunc__ doesn't get called from C AFAIK.
I thought the __trunc__ method only gets called from
the C code for the
I want to add test cases for int.__format__(), and I went looking for
Lib/test/test_int.py. I've added tests into Lib/test/test_long.py, so I
assumed there was an int version, but no.
Is there any particular reason for that, and are there int tests
elsewhere? If not, I'll add test_int.py,
When backporting PEP 3101, do we want to add __format__ to classic
classes? If so, could someone give me a pointer on how to implement
this? I don't see where to hook it up.
Thanks.
Eric.
___
Python-Dev mailing list
Python-Dev@python.org
Guido van Rossum wrote:
On Feb 13, 2008 5:28 AM, Eric Smith [EMAIL PROTECTED] wrote:
When backporting PEP 3101, do we want to add __format__ to classic
classes? If so, could someone give me a pointer on how to implement
this? I don't see where to hook it up.
You just have to get
Guido van Rossum wrote:
On Feb 13, 2008 9:48 AM, Eric Smith [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On Feb 13, 2008 5:28 AM, Eric Smith [EMAIL PROTECTED] wrote:
When backporting PEP 3101, do we want to add __format__ to classic
classes? If so, could someone give me a pointer on how
Guido van Rossum wrote:
Much to my surprise, this already works:
format(oldstyle(), '+^50s')
'+__main__.oldstyle instance at 0x3d91f8+'
So I guess it's a moot point. I'm using the same code as I use in 3.0,
where I call:
meth = _PyType_Lookup(Py_TYPE(value), format_str);
Nick Coghlan wrote:
Eric Smith wrote:
I hate to be dense, but could you point me to some code that does
something similar but looks up the method by name?
I was going to suggest __enter__/__exit__, but that code relies mainly
on existing opcodes and just does an attribute lookup rather
Guido van Rossum wrote:
On Feb 13, 2008 2:20 PM, Eric Smith [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
Eric Smith wrote:
I hate to be dense, but could you point me to some code that does
something similar but looks up the method by name?
I was going to suggest __enter__/__exit__
[slight mailer problem, this might show up as a dupe. sorry]
Guido van Rossum wrote:
On Feb 13, 2008 2:57 PM, Eric Smith [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On Feb 13, 2008 2:20 PM, Eric Smith [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
However, the source code for cPickle may
Guido van Rossum wrote:
Try this:
if (PyInstance_Check(obj)) {
bound_method = PyObject_GetAttr(obj, str__format__);
if (!bound_method)
return NULL;
call it passing only the format string
Py_DECREF(bound_method);
return whatever the call returned
}
else {
do it the py3k
While implementing .format(), I need to call the builtin format()
function, which I've already implemented (in
bltinmodule.c:builtin_format()). In the py3k branch, I just hardcoded
the same functionality into .format(), which seems like the wrong
thing to do, given how complex the code is.
I
Greg Ewing wrote:
Eric Smith wrote:
1: exposing builtin_format(), probably giving it another name
(PyObject_Format?) and moving it somewhere other than bltinmodule.c.
PyObject_Format sounds more like an API for invoking the
__format__ lookup mechanism. Maybe something like
Greg Ewing wrote:
Eric Smith wrote:
1: exposing builtin_format(), probably giving it another name
(PyObject_Format?) and moving it somewhere other than bltinmodule.c.
PyObject_Format sounds more like an API for invoking the
__format__ lookup mechanism. Maybe something like
Eric Smith wrote:
Greg Ewing wrote:
Eric Smith wrote:
1: exposing builtin_format(), probably giving it another name
(PyObject_Format?) and moving it somewhere other than bltinmodule.c.
PyObject_Format sounds more like an API for invoking the
__format__ lookup mechanism. Maybe something
Eric Smith wrote:
Guido van Rossum wrote:
For data types whose output uses only ASCII, would it be acceptable if
they always returned an 8-bit string and left it up to the caller to
convert it to Unicode? This would apply to all numeric types. (The
date/time types have a strftime() style API
André Malo wrote:
I guess, a clean and complete solution (besides re-implementing the whole
thing) would be to resolve each single format character with strftime,
decode according to the locale and re-assemble the result string piece by
piece. Doh!
That's along the lines of what I was
The tests for float.__format__ are breaking on Windows, because of this
issue: http://bugs.python.org/issue1600. Basically, Windows is using 3
digits for exponents 100, and Linux (and at least MacOS) are using 2.
The patch attached to the issue proposes changing all platforms to use
at least
André Malo wrote:
* Eric Smith wrote:
But now that I look at time.strftime in py3k, it's converting the entire
unicode string to a char string with PyUnicode_AsString, then converting
back with PyUnicode_Decode.
Looks wrong to me, too... :-)
nd
I don't understand Unicode encoding
Raymond Hettinger wrote:
[Eric Smith]
Speaking for myself, these features are generally useful,
and are so even without the new integer literal syntax.
I'm curious how these are useful to you in Py2.6 where
they are not invertible. In Py3.0, we can count on
x == int(bin(x), 2)
x
Raymond Hettinger wrote:
[Eric Smith]
I'm going to work on backporting PEP 3127, specifically
the hex, oct(), and bin() builtins.
IMO, these should not be backported. They are strongly
associated with 3.0's new literal syntax. They don't
don't really fit in with 2.6 and don't make 2.6
Robert Brewer wrote:
Raymond Hettinger wrote:
I thought the whole point of 3.0 was a recognition that all that
doubling-up was a bad thing and to be rid of it. Why make the
situation worse? ISTM that we need two versions of oct() like
we need a hole in the head. Heck, there's potentially a
Guido van Rossum wrote:
I wonder if, in order to change the behavior of various built-in
functions, it wouldn't be easier to be able to write
from future_builtins import oct, hex # and who knows what else
This makes sense to me, especially if we have a 2to3 fixer which removes
this line.
Robert Brewer wrote:
Eric Smith wrote:
Robert Brewer wrote:
Postgres bytea coercion is a frequent use case for oct() in my
world.
But I agree we don't need two versions.
Unless you're trying to write code to work with both 2.6 and 3.0.
Who would try that when PEP 3000 says (in bold type
Georg Brandl wrote:
Eric Smith schrieb:
Guido van Rossum wrote:
I wonder if, in order to change the behavior of various built-in
functions, it wouldn't be easier to be able to write
from future_builtins import oct, hex # and who knows what else
This makes sense to me, especially if we have
Guido van Rossum wrote:
I don't think a -3 warning for oct or hex would do any good.
I'm curious as to why. oct and hex have different behavior in 3.0,
which is what I thought -3 was for. hex might be overkill, as the only
differences are the L and the __hex__ behavior. But oct is always
Barry Warsaw wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 28, 2008, at 2:49 PM, Christian Heimes wrote:
Hey Barry!
Hi Christian!
When are you planing to freeze the code of the trunk and branches/py3k
for the upcoming alpha releases? I'll merge the last modifications
Barry Warsaw wrote:
Okay, let's go ahead and make it official.
I plan on cutting the alphas for 2.6 and 3.0 at about 6pm Eastern
(UTC-5) time or 2300 UTC. Let's freeze the tree one hour prior to
that: 2200 UTC Friday 29-Feb-2008.
Argh! I was going to check the last of the PEP 3127
Barry Warsaw wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 28, 2008, at 4:03 PM, Eric Smith wrote:
Barry Warsaw wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 28, 2008, at 2:49 PM, Christian Heimes wrote:
Hey Barry!
Hi Christian!
When are you planing
In the keynote, Guido mentioned switching from range to xrange in 2.6
code, as a migration strategy. Another option would be to add range to
future_builtins, and have it call xrange. Would that be desirable?
___
Python-Dev mailing list
Kristján Valur Jónsson wrote:
Aha, thanks, since my wireshark wasn't working.
I boiled a few pints of water (thanks, Google) and came up with this:
http://support.microsoft.com/kb/175523
Here is the summary:
Note that with other implementations of TCP, such as those commonly found in
many
Terry Reedy wrote:
Cameron Simpson wrote:
Back at uni we had to implement a small language in our compilers class
and the lecturer had specified a proper generic while loop, thus:
loop:
suite
while invariant
suite
endloop
In Python, that is spelled
while True:
suite
if
s...@pobox.com wrote:
From configure.in:
# The current (beta) Monterey compiler dies with optimizations
# XXX what is Monterey? Does it still die w/ -O? Can we get rid of this?
case $ac_sys_system in
Monterey*)
OPT=
;;
esac
What is Monterey?
Terry Reedy wrote:
Ron Adam wrote:
Steven D'Aprano wrote:
Michael Foord wrote:
Don't we have a pretty-print API - and isn't it spelled __str__ ?
Not really. If it were as simple as calling str(obj), there would be
no need for the pprint module.
I agree. And when I want to use pprint,
Aahz wrote:
On Tue, Feb 03, 2009, Ross Light wrote:
Hello, python-dev. I submitted a patch a couple weeks ago for Issue
4285, and it has been reviewed and revised. Would someone please
review/commit it? Thank you.
http://bugs.python.org/issue4285
When sending in a request like this, it's
Calvin Spealman wrote:
I would favor this not being constrained. I don't want every use of **
to cause a pattern match to verify each key. I would even be fine
without the check for being strings. Define what it should be, but let
the implementation be lax. It is no different from any other
Eric Smith wrote:
Aahz wrote:
On Tue, Feb 03, 2009, Ross Light wrote:
Hello, python-dev. I submitted a patch a couple weeks ago for Issue
4285, and it has been reviewed and revised. Would someone please
review/commit it? Thank you.
http://bugs.python.org/issue4285
When sending
In the trunk, test_tk_guionly hangs if I run it through regrtest. This
is on a Fedora Core 6 box, without X installed.
If I run test_tk_guionly directly, it exits saying there's no DISPLAY
set, which is what I'd expect:
--8--
[trunk]$ ./python Lib/test/test_ttk_guionly.py
Guilherme Polo wrote:
On Fri, Feb 6, 2009 at 1:14 PM, Eric Smith e...@trueblade.com wrote:
In the trunk, test_tk_guionly
test_ttk_guionly, right ?
Right, sorry.
hangs if I run it through regrtest. This is on
a Fedora Core 6 box, without X installed.
Does it hang if you run it alone
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
Antoine Pitrou wrote:
Eric Smith eric at 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!
___
Python
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
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 distinction worth pointing out.
Proposal
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
complexity
anatoly techtonik wrote:
Correct me if I wrong, but shouldn't Python include function for
version comparisons?
snip
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
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
Olemis Lang wrote:
On Fri, Mar 27, 2009 at 5:22 AM, Paul Moore p.f.mo...@gmail.com wrote:
2009/3/27 Guido van Rossum gu...@python.org:
- 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
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
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
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
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
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
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 now, isn't
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
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
-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 m...@egenix.com 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 this
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 like to get
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
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
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
Ned Deily wrote:
In article 49e3d34e.8040...@trueblade.com,
Eric Smith e...@trueblade.com 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
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
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
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. Basically, the float-string
Mark Dickinson wrote:
On Fri, Apr 24, 2009 at 9:25 PM, Terry Reedy tjre...@udel.edu 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
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 checked the changes
Benjamin Peterson wrote:
2009/4/24 Eric Smith e...@trueblade.com:
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
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:
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
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
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.
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,
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
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
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:
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:
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'
Apparently, precision is _not_ ignored?
That section is talking
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/textio.c
Tarek Ziadé wrote:
On Thu, May 7, 2009 at 11:36 PM, Eric Smith e...@trueblade.com 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, until then
you can
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
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
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 p.f.moore at 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
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 with some
Paul Moore wrote:
2009/7/8 P.J. Eby p...@telecommunity.com:
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
1 - 100 of 329 matches
Mail list logo
