Re: [Python-Dev] repeated keyword arguments
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 alone (too much risk of breaking code) but
fix it in 2.6 and 3.0 if we can.
I think code that uses this is probably already quite broken in some
fundamental way and putting the fix in 2.5 isn't much of a risk.
I don't have 2.4 handy to test it, but it is more likely that a
keyword and dictionary are passed, both containing the same item:
>>> f(a=3, **{'a': 4})
Would that be a potential risk?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: add odict to collections
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 found this useful. And, as far as questions about the definition of an ordered dictionary, is there any good reason not to simply treat the dict as a list? Something like (with the obvious bits left out): class odict(dict): def __init__(self, *args): self._order = [] def __setitem__(self, key, val): if key not in self: self._order.append(key) def __iter__(self): return self._order def items(self): return ([item, self[item] for item in self._order]) def sort(self): self._order.sort() ... and so on ... That way all the order-related functions are well defined, so it would be hard claim that it doesn't do the "right thing" without claiming that lists don't do the "right thing". ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encoding detection in the standard library?
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 are talking about browsers specifically, which
need to support web pages that specify the encoding incorrectly.
Two cases come immediately to mind: email and web forms.
When a web browser POSTs data, there is no standard way of
communicating which encoding it's using. There are some hints which
make it easier (accept-charset attributes, the encoding used to send
the page to the browser), but no guarantees.
Email is a smaller problem, because it usually has a helpful content-
type header, but that's no guarantee.
Now, at the moment, the only data I have to support this claim is my
experience with DrProject in non-English locations.
If I'm the only one who has had these sorts of problems, I'll go back
to "Unicode for Dummies".
so it might as well be built in; I would prefer the option
to run `text=input.encode('guess')` (or something similar) than
relying
on an external dependency or worse yet using a hand-rolled algorithm.
Ok, let me try differently then. Please feel free to post a patch to
bugs.python.org, and let other people rip it apart.
For example, I don't think it should be a codec, as I can't imagine it
working on streams.
As things frequently are, it seems like this is a much larger problem
that I originally believed.
I'll go back and take another look at the problem, then come back if
new revelations appear.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encoding detection in the standard library?
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 that should be part of the standard library. People
will mistake what it tells them for certain.
As Oleg mentioned, if the method is called something like
'guess_encoding', I think we could live with clear consciences.
IMO, encoding estimation is something that many web programs will
have to deal with, so it might as well be built in; I would prefer
the option to run `text=input.encode('guess')` (or something similar)
than relying on an external dependency or worse yet using a hand-
rolled algorithm.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encoding detection in the standard library?
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 > determine the > encoding of a chunk of text 100% of the time mitigates against it. Sorry, I wasn't very clear what I was asking. I was thinking about making an educated guess -- just like chardet (http://chardet.feedparser.org/). 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). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Encoding detection in the standard library?
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 thread. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] string representation of range in 3.0
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 >>> built-in >>> iterators and iterables, instead of their mosty-useless default >>> repr. >> >> I quite like this. But as a non-beginner, I'll freely admit that my >> intuitions are suspect :-) > > I like this too. For iterators, though, would you always show the > next > couple of elements? The values "contained in" the iterator will > change as > the iterator iterates. Alternatively, the representation could be > "frozen" to reflect the values originally pending in the iterator, but > then the representation wouldn't show anything about the current > state of > the iterator. So would you mean something like: , <__main__.Foo instance at 0x83620>, ...> Or maybe: , <__main__.Foo instance at 0x83620>, ... > While I agree in theory, I'm not sure I like the looks of it in practise. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2to3 speedup patch
Under the instruction of Martin, I've made some small changes to 2to3 so keeps track of which fixers act on which level of node. The speedup isn't too shabby: running on the example file, processing time went from 9 to 7 seconds, and the test suite dropped from 400 to 350. 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 MSN: [EMAIL PROTECTED] Phone: 416-906-0403 "Without payment you have received; without payment you are to give." (Mat 10:8 ISV) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2to3 and print function
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. > Auto-detection based on __future__ would be a good thing to have > (assuming that __future__ statement has actually been implemented :-). The __future__ statement has been implemented, so __future__ auto- detection will come shortly :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2to3 and print function
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: -tree = self.driver.parse_string(data) -except parse.ParseError, e: -if e.type == token.EQUAL: -tree = self.printless_driver.parse_string(data) -else: -raise Why not, instead of trying both parsers, scan for a __future__ import, then do the Right Thing based on that? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Pretty-printing 2to3 Nodes
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 (279:dotted_as_name, [Node(281:dotted_name, [Leaf(1, 'foo'), Leaf(23, '.'), Leaf(1, 'bar')]), Leaf(1, 'as'), Leaf(1, 'bang')])]), Leaf(4, '\n')]) OR just names: Node(import_name, [Leaf(1, 'import'), Node(dotted_as_name, [Node (dotted_name, [Leaf(1, 'foo'), Leaf(23, '.'), Leaf(1, 'bar')]), Leaf (1, 'as'), Leaf(1, 'bang')])]) OR the original: Node(313, [Node(298, [Leaf(1, 'import'), Node(279, [Node(281, [Leaf (1, 'foo'), Leaf(23, '.'), Leaf(1, 'bar')]), Leaf(1, 'as'), Leaf(1, 'bang')])]), Leaf(4, '\n')]) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2to3 and print function
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 x.py: ParseError: bad input: type=22,
value='=', context=('', (2, 26))
What would be the best way to start fixing this?
#2412 is the related bug.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Order of Fixers
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 digging around a bit and there is the option to traverse the tree in preorder or postorder. While the actual order does not matter in this case, what does matter is that the preorder fixers are run first -- so I've just dropped the print fixer in there (and commented everything). This isn't a great general solution... But, at the moment, there is no need for it to be. If the need for a general solution arises, that can be added :)___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Order of Fixers
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 fix_zz_future... But that has some obvious drawbacks. Alternately, if future is the only dependent module, it might be marginally cleaner to simply special-case it in refactor.get_all_fix_names. So, any better suggestions? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] map, filter, zip in future_builtins
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 that.___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] map, filter, zip in future_builtins
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])) == map >> False > Doesn't strike me as a terrible problem. Excellent, I'll go ahead and do the same thing with filter and zip. > Why is the latter == failing? What's the different between > type(map(...)) and map? Because future_builtins.map imports and returns itertools.imap: def map(*args): from itertools import imap return imap(*args) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] map, filter, zip in future_builtins
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 behaviour seems to be identical. The disadvantage is that the two aren't identical: >>> type(map(lambda x: x, [1, 2, 3])) # Python 3 >>> type(map(lambda x: x, [1, 2, 3])) == map True >>> type(map(lambda x: x, [1, 2, 3])) # Python 2.6, with the patch >>> type(map(lambda x: x, [1, 2, 3])) == map False Recommendations? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
