On 3/1/2011 4:19 PM, Kerrick Staley wrote:
Hello,
There is a need for the default Python2 install to place a symlink at
/usr/bin/python2 that points to /usr/bin/python, or for the
documentation to recommend that packagers ensure that python2 is
defined. Also, all documentation should be changed t
On 3/5/2011 7:37 PM, "Martin v. Löwis" wrote:
I am trying to fix the hgeol settings for the vcproj files, with little
success so far. I created
http://hg.python.org/sandbox/hgeol/
which merely changes the .hgeol file. Now, if you enable the eol
extension, and check this branch out, you immediat
On 3/9/2011 7:55 AM, Mark Shannon wrote:
Hi,
I hope this is the right place to ask this.
Do anyone know why the str (unicode) object is implemented
with an external buffer like list, rather than internal one like
tuple and bytes?
Would anything bad happen if it were changed?
I'm not suggesting
On 03/11/2011 06:03 PM, antoine.pitrou wrote:
If you want to try out or review a patch generated using Mercurial, do::
- hg import --no-commit somework.patch
+ patch -p1< somework.patch
This will apply the changes in your working copy without committing them.
If the patch was not cre
Could someone with the right access add a "Python 3.4" version to the
tracker? I have a deprecation warning that I need to make an error in 3.4.
I'd also like to make it a release blocker in 3.4 so I don't forget
about it. If I do that, will it screw up any release workflow?
Thanks.
_
On 03/12/2011 10:55 AM, Éric Araujo wrote:
I have a deprecation warning that I need to make an error in 3.4.
A neat trick to remember to do those changes is using a test that fails
if something does not raise a DeprecationWarning if sys.version_info[:2]
== (3, 3), or an error if sys.version_inf
On 03/13/2011 06:49 AM, Georg Brandl wrote:
On 12.03.2011 17:09, Eric Smith wrote:
On 03/12/2011 10:55 AM, Éric Araujo wrote:
I have a deprecation warning that I need to make an error in 3.4.
A neat trick to remember to do those changes is using a test that fails
if something does not raise
On 03/14/2011 02:33 AM, Greg Ewing wrote:
Tim Lesher wrote:
Because named tuple prefixes a single underscore to its added method
names (_asdict, _replace, and _make), those methods' docstrings are
omitted from pydoc:
IMO these should be called __asdict__, __replace__ and
__make__. Users are p
On 03/14/2011 07:46 AM, Antoine Pitrou wrote:
On Mon, 14 Mar 2011 06:29:09 -0400
Eric Smith wrote:
On 03/14/2011 02:33 AM, Greg Ewing wrote:
Tim Lesher wrote:
Because named tuple prefixes a single underscore to its added method
names (_asdict, _replace, and _make), those methods' docst
On 3/14/2011 8:44 PM, James Mills wrote:
On Tue, Mar 15, 2011 at 9:48 AM, R. David Murray wrote:
But directly calling a __xxx__ method in Python is a very
unusual thing to do. It would be extremely odd to have that
be the expected way to call a method on a class.
Can't namedtuple be improved
On 03/14/2011 10:02 PM, James Mills wrote:
On Tue, Mar 15, 2011 at 11:50 AM, Terry Reedy wrote:
How would that work if you had a field named "replace"? I think
Raymond's current design is as good as it's going to get.
'as_dict' is an unlikely fieldname. 're_place' is too, but that just shift
On 03/15/2011 08:07 PM, Andrew Svetlov wrote:
As PEP 3101 http://www.python.org/dev/peps/pep-3101/ says (and current
Python does) user can specify conversions like "{0!s}".
In custom formatters (derived from string.Formatter) he can override
convert_field method to add custom conversions.
I expe
On 3/15/2011 10:58 PM, Lennart Regebro wrote:
On Tue, Mar 15, 2011 at 22:42, Guido van Rossum wrote:
Fortunately there may not be any more such cases since no new major
versions of Python 2 will be released. So I'm not sure what an update
of PEP 5 will buy us.
That is a good point. But at lea
On 3/16/2011 5:54 PM, Alexander Belopolsky wrote:
On Wed, Mar 16, 2011 at 3:00 PM, Raymond Hettinger
wrote:
..
The version number in the decimal module refers to the version of the
spec that is being complied with. I would like that version number
to remain in the module.
I mentioned this i
On 3/16/2011 11:58 PM, Jesus Cea wrote:
I agree that half the changesets are merges now.
Which has basically stopped me from reviewing changes. I can't quickly
tell the real changes from the noise of merges.
___
Python-Dev mailing list
Python-Dev@py
On 3/17/2011 6:28 AM, Georg Brandl wrote:
Am 17.03.2011 09:57, schrieb Eric Smith:
On 3/16/2011 11:58 PM, Jesus Cea wrote:
I agree that half the changesets are merges now.
Which has basically stopped me from reviewing changes. I can't quickly
tell the real changes from the noise of m
On 03/17/2011 03:08 PM, Jesus Cea wrote:
I would suggest to keep deprecating things in 3.x, BUT keeping the
deprecated stuff around (maybe reimplementing them using the new stuff)
until we decide is safe to axe it, instead of the regular 3.x
deprecates, 3.(x+1) cleans up.
At some point, didn't
> On Mon, 21 Mar 2011 04:09:35 +0100
> "Martin v. Löwis" wrote:
>> Since Python 2.5, we maintain two versions of PyArg_ParseTuple:
>> one outputting int; the other one outputting Py_ssize_t.
>>
>> The former should have been removed in 3.0, but this was forgotten.
>>
>> Still, I would like people
>>
>> >> Given the recent discussion about backwards compatibility: what's
>> >> the best approach? What warning should be emitted, if any?
>> >> (the warning would only be generated if an s# or similar format
>> >> was actually encountered - not just if merely PyArg_ParseTuple is
>> >> called).
> On Thu, Mar 24, 2011 at 10:50:51AM -0700, Guido van Rossum wrote:
>> The JSON use case seems to be driven because this is the way
>> JavaScript does things -- they don't distinguish between dicts and
>> objects.
>
>That's particular feature has a cure (or poison - for thos who don't
> want to
On 3/24/2011 8:10 PM, Eugene Toder wrote:
Although we do something similar with namedtuple (instead of using a
dict), so it's not like we have a strict distinction.
Named tuple is a convenience to avoid creating boilerplate classes (or
resorting to use dict with well-known keys).
My point is
On 4/1/2011 6:46 AM, Georg Brandl wrote:
> Am 31.03.2011 19:35, schrieb Éric Araujo:
>>> I would like to apply this patch (or its moral equivalent) to all active,
>>> affected branches of Python, meaning 2.5 through 2.7, and 3.1 through 3.3,
>>> as
>>> soon as possible. Without this, it will be v
On 4/1/2011 3:52 PM, "Martin v. Löwis" wrote:
>> And I don't see a problem with build fixes. It's not like we're adding
>> language features. If it makes someone's life easier, then what's the harm?
>
> It's extra work with no volunteer doing it.
I understood Barry was volunteering. Certainly if
On 4/3/2011 12:20 PM, antoine.pitrou wrote:
> http://hg.python.org/cpython/rev/c11e05a60d36
> changeset: 69115:c11e05a60d36
> parent: 69113:ff105faf1bac
> parent: 69114:88ed3de28520
> user:Antoine Pitrou
> date:Sun Apr 03 18:16:50 2011 +0200
> summary:
> Merge fix for
> On Thu, Apr 7, 2011 at 7:01 AM, Benjamin Peterson
> wrote:
>> 2011/4/6 anatoly techtonik :
>>> Is it a good idea to have code highlighting in tracker?
>>
>> Why would we need it?
>
> Because tracker is ugly.
That's not a good enough reason. I'm -1 on adding this: it's yet another
thing to maint
On 05/09/2011 03:17 PM, Guido van Rossum wrote:
> On Mon, May 9, 2011 at 11:36 AM, Ned Batchelder
> wrote:
>> On 5/9/2011 1:24 PM, Terry Reedy wrote:
>>>
>>> A commit (push) partition time and behavior into before and after (with a
>>> short change period in between during which behavior is undef
On 05/18/2011 12:16 PM, Stephen J. Turnbull wrote:
> Robert Collins writes:
>
> > Its probably too late to change, but please don't try to argue that
> > its correct: the continued confusion of folk running into this is
> > evidence that confusion *is happening*. Treat that as evidence and
> >
On 5/18/2011 6:32 PM, Greg Ewing wrote:
> Eric Smith wrote:
>
>> And of course it's too late to make any change to this.
>
> It's too late to change the meaning of b'...', but is it
> really too late to introduce an x'...' literal and ch
> Victor Stinner wrote:
>> I already patched the doc of the random module to add a security
>> warning. Well, you don't really need to know how a CSPRNG is
>> implemented, just that random cannot be used for security and that
>> ssl.RAND_bytes() raises an error if was seeded with enough data.
>>
>>
On 05/25/2011 06:58 AM, Petri Lehtinen wrote:
> Eric Smith wrote:
>>> Victor Stinner wrote:
>>>> I already patched the doc of the random module to add a security
>>>> warning. Well, you don't really need to know how a CSPRNG is
>>>> implemen
On 5/25/2011 1:17 PM, Victor Stinner wrote:
> Le mercredi 25 mai 2011 à 18:46 +0200, Charles-François Natali a écrit :
>> While we're at it, adding a "recursive" argument to this shutil.chown
>> could also be useful.
>
> I don't like the idea of a recursive flag. I would prefer a "map-like"
> func
On 5/26/2011 8:32 AM, Victor Stinner wrote:
> Le jeudi 26 mai 2011 à 08:13 -0400, Eric Smith a écrit :
>> If you're ever going to add code at the end of these functions, it's
>> unlikely you'll remember that you need to add these increments back in.
>
> You don
On 5/26/2011 10:34 AM, Ronald Oussoren wrote:
>
> On 26 May, 2011, at 16:10, Eric Smith wrote:
>>
>>
>>> and make silent the Clang Static Analyzer :-)
>>
>> I care less about that than maintainability and future-proofing.
>
> Have to looked at the pat
So, given the discussions about this change, can you please revert it,
Victor?
Eric.
On 05/26/2011 08:07 AM, victor.stinner wrote:
> http://hg.python.org/cpython/rev/7ba176c2f558
> changeset: 70397:7ba176c2f558
> user:Victor Stinner
> date:Thu May 26 13:53:47 2011 +0200
> summa
> Plist and Dict were never documented (in Doc/library/plistlib.rst).
> These classes have no test.
Ouch!
> You mean that I should add an entry to Misc/NEWS saying that these
> classe are now deprecated? Should I also mention the deprecation to the
> "What's new in Python 3.3?" document?
Yes. I
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
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
(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 few
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 P
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, in order
Guido van Rossum wrote:
> On Jan 10, 2008 9:57 AM, Eric Smith <[EMAIL PROTECTED]> wrote:
>> Eric Smith wrote:
>>> 1: How should the builtin format() work? It takes 2 parameters, an
>>> object o and a string s, and returns o.__format__(s). If s is None, it
>
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()
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:
> 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
> question of "is this platform a UNIX or is it not a UN
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 wa
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 ve
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 cod
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, but
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
http://mail.
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 h
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
&
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_TY
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
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 meth
[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:
>>>> Nic
Guido van Rossum wrote:
> Try this:
>
> if (PyInstance_Check(obj)) {
> bound_method = PyObject_GetAttr(obj, str__format__);
> if (!bound_method)
> return NULL;
>
> Py_DECREF(bound_method);
> return
> }
> else {
> do it the py3k way;
> }
Yes! I had converged on something similar.
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 mech
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 mech
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 invo
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
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
I'm going to work on backporting PEP 3127, specifically the hex, oct(),
and bin() builtins. I have bin() completed, and I'll check it in
shortly. oct() will require a future import. Does anyone have any
pointers for implementing this? I understand (and have completed)
adding the future impo
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... :-)
>
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 c
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
&
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 poten
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
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 #
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
Guido van Rossum wrote:
> On Sat, Feb 23, 2008 at 9:01 AM, Eric Smith
> <[EMAIL PROTECTED]> wrote:
>> 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 differen
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 mo
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 th
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, Christia
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
Python-Dev@pyth
Yes, I know, and I'm looking at it. It doesn't fail on my Linux or Mac
OS X boxes. I'm trying to duplicate the problem. I'm going to try it
on my Windows box when I get home in about an hour. I'll fix it tonight.
I realize there's a beer riding on the buildbots being green!
Eric.
Trent Nel
I see the problem. Without -ucompiler, test_compiler doesn't compile
everything. I'll fix the breakage shortly.
Apologies.
Eric Smith wrote:
> Yes, I know, and I'm looking at it. It doesn't fail on my Linux or Mac
> OS X boxes. I'm trying to duplicate th
I've been double checking the PEP 3127 implementation in py3k and the
backport I did to 2.6. The PEP says this about the % operator:
"The string (and unicode in 2.6) % operator will have 'b' format
specifier added for binary, and the alternate syntax of the 'o' option
will need to be updated t
Nick Coghlan wrote:
> eric.smith wrote:
>> [EMAIL PROTECTED]
>> +def stdout_redirected(new_stdout):
>> +save_stdout = sys.stdout
>> +sys.stdout = new_stdout
>> +try:
>> +yield None
>> +finally:
>> +sys.stdout = save_stdout
>
> I think this test could easily be tweak
Trent Nelson wrote:
> Quick update on the status of the trunk buildbots:
>
> [x86 XP trunk (Joseph Armbruster)]
> This box didn't survive the recent build changes, but I can't figure out why,
> none of the other Windows boxes encounter this error:
> The following error has occurred during XML par
tion only.
Let me know if I can provide any other information. Unfortunately I
don't have access to this box during the work day (EDT), and I'm leaving
for vacation tomorrow (Friday). But I'll help as best I can.
Eric.
>
>
> Fro
Following up on a python-3000 discussion about making porting from 2.6
to 3.0 easier. Martin suggested making this its own thread.
This proposal is to add "from __future__ import
unicode_string_literals", which would make all string literals in the
importing module into unicode objects in 2.6.
Eric Smith wrote:
> This proposal is to add "from __future__ import
> unicode_string_literals", which would make all string literals in the
> importing module into unicode objects in 2.6.
I'm going to withdraw this, for 2 reasons.
1) The more I think about it, th
Christian Heimes wrote:
> Eric Smith schrieb:
> > It's not implementable because the work has to occur in ast.c (see
>> Py_UnicodeFlag). It can't occur later, because you need to skip the
>> encoding being done in parsestr(). But the __future__ import can only
Guido van Rossum wrote:
> On Tue, Mar 18, 2008 at 9:11 PM, Eric Smith
> <[EMAIL PROTECTED]> wrote:
>> I've been double checking the PEP 3127 implementation in py3k and the
>> backport I did to 2.6. The PEP says this about the % operator:
>>
>> "T
Martin v. Löwis wrote:
>> I'd call this a bug. The change is an accident, a side-effect of the fact
>> that in 2.5.1 the coefficient (mantissa) of a Decimal was stored as a
>> tuple, and in 2.5.2 it's stored as a string (which greatly improves
>> efficiency).
>> Clearly in 2.5.2 the mantissa is b
Alessandro Guido wrote:
> Can anybody please point me why print('a', 'b', sep=None, end=None) should
> produce "a b\n" instead of "ab"?
> I've read http://docs.python.org/dev/3.0/library/functions.html#print,
> pep-3105 and some
> ml threads but did not find a good reason justifying such a strange
Alessandro Guido wrote:
> Can anybody please point me why print('a', 'b', sep=None, end=None) should
> produce "a b\n" instead of "ab"?
> I've read http://docs.python.org/dev/3.0/library/functions.html#print,
> pep-3105 and some
> ml threads but did not find a good reason justifying such a strange
Alessandro Guido wrote:
> Can anybody please point me why print('a', 'b', sep=None, end=None) should
> produce "a b\n" instead of "ab"?
> I've read http://docs.python.org/dev/3.0/library/functions.html#print,
> pep-3105 and some
> ml threads but did not find a good reason justifying such a strange
[Sorry for the dupes. Lesson: never try and send mail from a moving train.]
Eric Smith wrote:
> Alessandro Guido wrote:
>> Can anybody please point me why print('a', 'b', sep=None, end=None) should
>> produce "a b\n" instead of "ab&quo
Jesse Noller wrote:
Do you have the code posted someplace for this? I'd like to add it into
the tests I am running
It would also be interesting to see how pyprocessing performs.
Eric.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
Christian Heimes wrote:
Antoine Pitrou schrieb:
In order to avoid memory consumption issues there could be a centralized cache
as for regular expressions. It makes it easier to handle eviction based on
various parameters, and it saves a few bytes for string objects which are never
used as a form
Eric Smith wrote:
Eric Smith wrote:
Nick Coghlan wrote:
Secondly, the string % operator appears to have an explicit
optimisation for the 'just return str(self)' case. This optimisation
is missing from the new string format method.
I'll see if I can optimize this case.
Georg Brandl wrote:
Martin v. Löwis schrieb:
In any case, I'm willing to give the TLC to convert the whole stdlib
to str.format, so I just need your permission!
Please don't - not before % is actually deprecated (which I hope won't
happen until Python 4, with removal of % in Python 5, in the
Did some checkin emails get lost yesterday? I didn't see mail for a
checkin of mine, r63895. Looking at
http://mail.python.org/pipermail/python-checkins/2008-June/date.html, it
looks like r63887-r63898 are missing from the archive, too.
We should probably make an effort to review those check
Barry Warsaw wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 3, 2008, at 6:55 AM, Eric Smith wrote:
Did some checkin emails get lost yesterday? I didn't see mail for a
checkin of mine, r63895. Looking at
http://mail.python.org/pipermail/python-checkins/2008-June/date.html
Martin v. Löwis wrote:
- reorganizing the tests into separate directories
Why this one?
I always find it hard to find a test I'm looking for in a directory
with 365 different tests in it. Also grouping tests by function will
hopefully help reduce duplication and it more intuitive.
Still, I do
201 - 300 of 347 matches
Mail list logo
