On 27-Jun-08, at 6:23 PM, Benjamin Peterson wrote:
On Fri, Jun 27, 2008 at 2:11 PM, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
Sounds like a regression in 2.5 (and in 2.6, and in 3.0). Probably
due
to the switch to the new AST-based compiler. Can you file a bug? I
think we should leave 2.5
On 14-Jun-08, at 8:39 PM, Armin Ronacher wrote:
...
I noticed lately that quite a few projects are implementing their own
subclasses of `dict` that retain the order of the key/value pairs.
...
I'm +1 on this one too, as there are at least a couple of times in
recent memory when I would have fou
On 22-Apr-08, at 12:30 AM, Martin v. Löwis wrote:
IMO, encoding estimation is something that many web programs will
have
to deal with
Can you please explain why that is? Web programs should not normally
have the need to detect the encoding; instead, it should be specified
always - unless you a
On 21-Apr-08, at 5:31 PM, Martin v. Löwis wrote:
This is useful when you get a hunk of data which _should_ be some
sort of intelligible text from the Big Scary Internet (say, a posted
web form or email message), and you want to do something useful with
it (say, search the content).
I don't think
On 21-Apr-08, at 12:44 PM, [EMAIL PROTECTED] wrote:
>
> David> Is there some sort of text encoding detection module is the
> David> standard library? And, if not, is there any reason not
> to add
> David> one?
> No, there's not. I suspect the fact that you can't correctly
> determ
Is there some sort of text encoding detection module is the standard
library?
And, if not, is there any reason not to add one?
After some googling, I've come across this:
http://mail.python.org/pipermail/python-3000/2006-September/003537.html
But I can't find any changes that resulted from that
On 16-Apr-08, at 9:37 AM, Isaac Morland wrote:
> On Wed, 16 Apr 2008, Paul Moore wrote:
>> On 16/04/2008, Armin Rigo <[EMAIL PROTECTED]> wrote:
>>> What about the less confusing and more readily generalizable:
>>>
>>>
>>> It would also be helpful IMHO to use this kind of repr for most
>>> buil
0.
I have attached the hacky, ugly, proof-of-concept patch to http://
bugs.python.org/issue2431
If there's no reason not to implement this sort of thing, I'll clean
it up and commit it when I get home (or something).
--
David Wolever - http://wolever.net/~wolever
AIM: davidswolever M
On 20-Mar-08, at 2:15 AM, Guido van Rossum wrote:
> On Wed, Mar 19, 2008 at 10:27 PM, David Wolever
> <[EMAIL PROTECTED]> wrote:
>> Why not, instead of trying both parsers, scan for a __future__
>> import, then do the Right Thing based on that?
> Different use cases
On 19-Mar-08, at 6:44 PM, Collin Winter wrote:
> You can pass -p to refactor.py to fix this on a per-run basis. See
> r58002 (and the revisions it mentions) for a failed attempt to do this
> automatically.
So, correct me if I'm wrong, but the relevant code is this:
-try:
-
Would anyone be averse to changing pytree.Node's __repr__ so it
includes the name of the name of the symbol the node represents?
The only downside is that it makes the __reprs__ longer... But I
think its worth the length:
Node(313:simple_stmt, [Node(298:import_name, [Leaf(1, 'import'), Node
At the moment, fix_print.py does the Right Thing when it finds ``from
__future__ import print_function``... But the 2to3 parser gets upset
when print() is passed kwargs:
$ cat x.py
from __future__ import print_function
print("Hello, world!", end=' ')
$ 2to3 x.py
...
RefactoringTool: Can't parse
On 19-Mar-08, at 2:18 PM, Benjamin Peterson wrote:
So, any better suggestions?
I would create a list of fixers that need to go first in
refactor.py and run those in order. If you wanted to get complex,
you could add a requires member to fixes, but that is probably
overkill.
Ok, so I was dig
At the moment, fixers are run in alphabetical order -- but this poses
a problem, because some depend on others (for example, fix_print will
need to be run _before_ fix_future, because fix_print looks for the
'from __future__ import ...' statement.
I'm tempted to simply change fix_future to f
On 18-Mar-08, at 6:01 PM, Benjamin Peterson wrote:
Couldn't you just import imap as map?
What do you mean? Import imap as map in future_builtins.c?
Like the Python:
import itertools
map = intertools.map
type(map(lambda x: x, range(3))) == map # True
Ah, that's a much better idea :P
I'll do t
On 18-Mar-08, at 5:10 PM, Guido van Rossum wrote:
> On Tue, Mar 18, 2008 at 3:54 PM, David Wolever
> <[EMAIL PROTECTED]> wrote:
>>>>> type(map(lambda x: x, [1, 2, 3])) # Python 2.6, with the patch
>>
>>>>> type(map(lambda x: x, [1, 2, 3])) ==
I'm working on #2171 -- putting map, filter, zip in 2.6's
future_builtins.
It has been suggested that it would be simplest to just return
itertools.(imap, izip, ifilter), which is what py3k/Python/
bltinmodule.c, revision 61356 did.
The advantage of this is that it's really easy and the behav
17 matches
Mail list logo
