Re: [Python-Dev] [Python-checkins] cpython (3.1): Do not add txt files twice.
I added the "if dir=='cjkencodings':" to msi.py, based on tests for other
subdirectories in Lib/tests/. Can you explain me why cjkencodings should not
have a special case? The fix should maybe be ported to 3.2, 3.3 and 2.7.
Victor
Le dimanche 05 juin 2011 11:00:30, martin.v.loewis a écrit :
> http://hg.python.org/cpython/rev/df7b9c5d6ba1
> changeset: 70643:df7b9c5d6ba1
> branch: 3.1
> parent: 70571:0639e630426c
> user:Martin v. Löwis
> date:Sun Jun 05 10:55:57 2011 +0200
> summary:
> Do not add txt files twice.
>
> files:
> Tools/msi/msi.py | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
>
> diff --git a/Tools/msi/msi.py b/Tools/msi/msi.py
> --- a/Tools/msi/msi.py
> +++ b/Tools/msi/msi.py
> @@ -1021,8 +1021,6 @@
> lib.add_file("zipdir.zip")
> if dir=='tests' and parent.physical=='distutils':
> lib.add_file("Setup.sample")
> -if dir=='cjkencodings':
> -lib.glob("*.txt")
> if dir=='decimaltestdata':
> lib.glob("*.decTest")
> if dir=='output':
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The socket HOWTO
On Sun, 05 Jun 2011 08:32:38 +0200 "Martin v. Löwis" wrote: > >> -1. I think there should be a Python-oriented introduction to sockets. > >> You may have complaints about the specific wording of the text, but > >> please understand that these are probably irrelevant to most > >> first-time readers of this text. My observation is that people actually > >> don't read the text that much, but instead try to imitate the examples. > > > > So what you're saying is that the text is mostly useless (or at least > > quite dispensable), but you think it's fine that people waste their > > time trying to read it? > > No, that's not what I said. I said the people actually *don't* read > the text, so they won't waste time with it. They only glance at the > text, enough to understand the examples. I'm sorry, that sounds like a very outlandish argument to make. Did you run a user survey? If people only "glance at the text", then what is the text for? Why not kill the text and rename the page "socket examples" so that there is no misunderstanding and so that we don't waste time trying to maintain (and argue about) it? > > I'm not sure why the examples are good (for example, modern client > > code should probably use create_connection() with a host name, not > > connect()). > > I disagree. create_connection is an advanced function - you shouldn't > be using it unless you know what it is doing. Can you explain? I would certainly use it myself, and I don't understand how it's "advanced". It's simply higher-level. Actually, we've been actually replacing uses of connect() with create_connection() in various parts of the stdlib, so that our client modules get IPv6-compatible. > No no no no no. Absolutely not. > a) telling people who want to learn sockets "don't learn sockets, >learn some higher-level library" is besides the point. What do >you tell them when they did that, and now come back to learn >sockets? You said yourself that the HOWTO doesn't claim to explain sockets, so how can you make such a point now? If people want to learn sockets for real, the HOWTO is hopeless for them. > I'd happily kill the entire non-blocking discussion from the tutorial > if it hurts you as much as it hurts me. +1. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] FWD: gpg keys have problems
I'm not currently reading python-dev, dunno if this has come up before: - Forwarded message from "Michael J. Dinneen" - > Date: Sun, 05 Jun 2011 19:33:04 +1200 > From: "Michael J. Dinneen" > To: [email protected] > Subject: gpg keys have problems > Organization: University of Auckland > > >From your python download page you need to update the public keys to not use > >the faulty MD5 digest algorithm. > (see the link listed below) > > $ gpg --import pubkeys.txt > gpg: key 6A45C816: public key "Anthony Baxter " > imported > gpg: WARNING: digest algorithm MD5 is deprecated > gpg: please see http://www.gnupg.org/faq/weak-digest-algos.html for more > information > gpg: key ED9D77D5: public key "Barry A. Warsaw " imported > gpg: Total number processed: 2 > gpg: imported: 2 (RSA: 1) > gpg: no ultimately trusted keys found > - End forwarded message - -- Aahz ([email protected]) <*> http://www.pythoncraft.com/ Looking back over the years, after I learned Python I realized that I never really had enjoyed programming before. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] keyword-only arguments and varags
2011/6/5 Nick Coghlan : > On Sun, Jun 5, 2011 at 11:45 AM, Benjamin Peterson > wrote: >> Currently, >> >> def f(*, kw, **kwargs): pass >> >> is valid syntax, but >> >> def f(*args, *, kw): pass >> >> is not. >> >> I don't see any mention of it in the PEP but perhaps there is a good >> reason this isn't allowed. It seems to be perfectly well-defined to >> me. > > Really? There's two single-stars there. One says "accept arbitrary > positional arguments and place them in a tuple named args", the second > says "don't accept any more positional args". You can't have it both > ways, so the compiler complains. Thank you. More proof I shouldn't write emails after 22:00 local time. > > The following works fine to mix keyword-only arguments with arbitrary > positional arguments, so I don't see a problem: > > def f(*args, kw): pass Move along, nothing to see here... -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The socket HOWTO
On Jun 4, 2011, at 11:32 PM, Martin v. Löwis wrote: > b) telling people to use Twisted or asyncore on the server side > if they are new to sockets is bad advice. People *first* have > to understand sockets, and *then* can use these libraries > and frameworks. Those libraries aren't made to be black boxes > that work even if you don't know how - you *have* to know how > they work inside, or else you can't productively use them. First, Twisted doesn't always use the BSD sockets API; the Windows IOCP reactor, especially, starts off with the socket() function, but things go off in a different direction pretty quickly from there. So it's perfectly fine to introduce yourself to networking via Twisted, and many users have done just that. If you're using it idiomatically, you should never encounter a socket object or file descriptor poking through the API anywhere. Asyncore is different: you do need to know how sockets work in order to use it, because you're expected to call .send() and .recv() yourself. (And, in my opinion, this is a serious design flaw, for reasons which will hopefully be elucidated in the PEP that Laurens is now writing.) Second, it makes me a little sad that it appears to be folk wisdom that Twisted is only for servers. A lot of work has gone into making it equally appropriate for clients. This is especially true if your client has a GUI, where Twisted is often better than a protocol-specific library, which may either be blocking or have its own ad-hoc event loop. I don't have an opinion on the socket HOWTO per se, only on the possibility of linking to Twisted as an alternate implementation mechanism. It really would be better to say "go use Twisted rather than reading any of the following" than "read the following, which will help you understand Twisted". ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The socket HOWTO
> On Jun 4, 2011, at 11:32 PM, Martin v. Löwis wrote: > >> b) telling people to use Twisted or asyncore on the server side >> if they are new to sockets is bad advice. People *first* have >> to understand sockets, and *then* can use these libraries >> and frameworks. Those libraries aren't made to be black boxes >> that work even if you don't know how - you *have* to know how >> they work inside, or else you can't productively use them. It would be fine to have a separate networking howto guide that covers libraries, frameworks, and high level APIs, but I agree with Martin that the Socket HOWTO needs to cover sockets. That's what a person expects to learn when they click on the Socket HOWTO link. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The socket HOWTO
>>> I'm not sure why the examples are good (for example, modern client >>> code should probably use create_connection() with a host name, not >>> connect()). >> >> I disagree. create_connection is an advanced function - you shouldn't >> be using it unless you know what it is doing. > > Can you explain? I would certainly use it myself, and I don't > understand how it's "advanced". It's simply higher-level. It uses getaddrinfo, which might return multiple addresses, which are then tried in sequence. So even though it's called "create_connection", it may actually attempt to create multiple connections. As a consequence, it may wait some time for one connection to complete, and then succeed on a different address. These phenomena can only be understood when you know what it is actually doing. > Actually, we've been actually replacing uses of connect() with > create_connection() in various parts of the stdlib, so that our > client modules get IPv6-compatible. And that's fine - the people making this changes most certainly where capable of using advanced API. >> No no no no no. Absolutely not. >> a) telling people who want to learn sockets "don't learn sockets, >>learn some higher-level library" is besides the point. What do >>you tell them when they did that, and now come back to learn >>sockets? > > You said yourself that the HOWTO doesn't claim to explain sockets Did I say that? If so, I didn't mean to. It explains how to use the socket API. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The socket HOWTO
> First, Twisted doesn't always use the BSD sockets API; the Windows IOCP > reactor, especially, starts off with the socket() function, but things > go off in a different direction pretty quickly from there. Hmm. Are you saying it doesn't use listen, connect, bind, send, recv? To me, that's the core of BSD sockets. I can understand it doesn't use select(2). > So it's > perfectly fine to introduce yourself to networking via Twisted, and many > users have done just that. If you're using it idiomatically, you should > never encounter a socket object or file descriptor poking through the > API anywhere. And that's all fine. I still claim that you have to *understand* sockets in order to use it properly. By this, I mean stuff like "what is a TCP connection? how is it established?", "how is UDP different from TCP?", "when data arrives, what layers of software does it go through?", "what is a port number?", etc. > Second, it makes me a little sad that it appears to be folk wisdom that > Twisted is only for servers. A lot of work has gone into making it > equally appropriate for clients. This is especially true if your client > has a GUI, where Twisted is often better than a protocol-specific > library, which may either be blocking or have its own ad-hoc event loop. I think that's because many of the problems that Twisted solves don't exist in many of the client applications - in particular, you often don't have many simultaneous connections. GUI apps may be the interesting special case, but I expect that people dealing with these rather use separate threads. > I don't have an opinion on the socket HOWTO per se, only on the > possibility of linking to Twisted as an alternate implementation > mechanism. It really would be better to say "go use Twisted rather than > reading any of the following" than "read the following, which will help > you understand Twisted". Wouldn't you agree that Twisted is very difficult to learn, and thus much heavier than sockets? And I don't blame the Twisted API for that, but rather the mental model of overlapping activities that people have severe problems with. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The socket HOWTO
On 5 Jun, 10:35 pm, [email protected] wrote: First, Twisted doesn't always use the BSD sockets API; the Windows IOCP reactor, especially, starts off with the socket() function, but things go off in a different direction pretty quickly from there. Hmm. Are you saying it doesn't use listen, connect, bind, send, recv? To me, that's the core of BSD sockets. I can understand it doesn't use select(2). Yes, that's correct. Those aren't the best APIs to use on Windows, so they aren't necessarily used on Windows. So it's perfectly fine to introduce yourself to networking via Twisted, and many users have done just that. If you're using it idiomatically, you should never encounter a socket object or file descriptor poking through the API anywhere. And that's all fine. I still claim that you have to *understand* sockets in order to use it properly. By this, I mean stuff like "what is a TCP connection? how is it established?", "how is UDP different from TCP?", "when data arrives, what layers of software does it go through?", "what is a port number?", etc. These may be good things to understand. The current socket howto doesn't explain them, though. Second, it makes me a little sad that it appears to be folk wisdom that Twisted is only for servers. A lot of work has gone into making it equally appropriate for clients. This is especially true if your client has a GUI, where Twisted is often better than a protocol-specific library, which may either be blocking or have its own ad-hoc event loop. I think that's because many of the problems that Twisted solves don't exist in many of the client applications - in particular, you often don't have many simultaneous connections. GUI apps may be the interesting special case, but I expect that people dealing with these rather use separate threads. On the contrary, many of the problems do exist in client applications (every time I have to use virt-manager I want to throw it out a window). Some people certainly would rather use threading, but that doesn't say anything about whether Twisted solves problems relevant to clients, only about the fact that a lot of people like to use threads. I don't have an opinion on the socket HOWTO per se, only on the possibility of linking to Twisted as an alternate implementation mechanism. It really would be better to say "go use Twisted rather than reading any of the following" than "read the following, which will help you understand Twisted". Wouldn't you agree that Twisted is very difficult to learn, and thus much heavier than sockets? And I don't blame the Twisted API for that, but rather the mental model of overlapping activities that people have severe problems with. This discussion has a significant problem, in taking "Twisted" as a monolithic all-or-nothing entity. Restricting the scope to merely the lowest-level socket replacement APIs - ie, the bare TCP, UDP, etc functionality - no, Twisted is not very difficult to learn. Expanding the scope to include the higher level functionality, it is much easier to learn than reimplementing line parsing and concurrency and so forth. However, does that really have anything to do with improving the socket howto? The Python documentation can include a clear explanation of what functionality the socket module provides - without forcing you to read Stevens _or_ use Twisted, but it can still refer you to both, since it is very likely that you'll need at least one of them in addition to the socket module. Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Add LRUCache class to stdlib
I would like to propose adding a class to the stdlib to provide a more flexible LRU caching mechanism. As things stand, the functools.lru_cache() decorator is fine for memoization of pure functions, but does not accommodate situations where cache entries become stale and must be invalidated/updated (e.g. filecmp.cmp(); cf. issue #11802). I was thinking it would be a good idea to factor out the the replacement code into a separate class that could then be reused by code for which the lru_cache() decorator is not applicable. The implementation of lru_cache() itself would also become considerably simpler. Implementation: class LRUCache: """Least-recently-used cache class. See: http://en.wikipedia.org/wiki/Cache_algorithms#Least_Recently_Used """ def __init__(self, maxsize): """Initialize an LRUCache. If *maxsize* is None, the LRU replacement mechanism is disabled, and the cache can grow without bound. """ if maxsize is None: self.cache = dict() else: self.cache = OrderedDict() self.lock = Lock() self.hits = self.misses = 0 self.maxsize = maxsize def __getitem__(self, key): with self.lock: try: value = self.cache[key] except KeyError: self.misses += 1 raise else: self.hits += 1 if self.maxsize is not None: self.cache.move_to_end(key) return value def __setitem__(self, key, value): with self.lock: self.cache[key] = value if self.maxsize is not None and len(self.cache) > self.maxsize: self.cache.popitem(0) def info(self): """Report cache statistics""" with self.lock: return _CacheInfo(self.hits, self.misses, self.maxsize, len(self.cache)) I'm not sure where this class should go; it would be convenient to just stick it in functools along with lru_cache(), but perhaps the collections package would be more appropriate? Cheers, Nadeem ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
