Re: [Python-Dev] sum(...) limitation
On Sat, Aug 02, 2014 at 05:39:12PM +1000, Steven D'Aprano wrote: > Repeated list and str concatenation both have quadratic O(N**2) > performance, but people frequently build up strings with + and rarely > do the same for lists. String concatenation with + is an attractive > nuisance for many people, including some who actually know better but > nevertheless do it. Also, for reasons I don't understand, many people > dislike or cannot remember to use ''.join. join() isn't preferable in cases where it damages readability while simultaneously providing zero or negative performance benefit, such as when concatenating a few short strings, e.g. while adding a prefix to a filename. Although it's true that join() is automatically the safer option, and especially when dealing with user supplied data, the net harm caused by teaching rote and ceremony seems far less desirable compared to fixing a trivial slowdown in a script, if that slowdown ever became apparent. Another (twisted) interpretation is that since the quadratic behaviour is a CPython implementation detail, and there are alternatives where __add__ is constant time, encouraging users to code against implementation details becomes undesirable. In our twisty world, __add__ becomes *preferable* since the resulting programs more closely resemble pseudo-code. $ cat t.py a = 'this ' b = 'is a string' c = 'as we can tell' def x(): return a + b + c def y(): return ''.join([a, b, c]) $ python -m timeit -s 'import t' 't.x()' 100 loops, best of 3: 0.477 usec per loop $ python -m timeit -s 'import t' 't.y()' 100 loops, best of 3: 0.695 usec per loop David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #22003: When initialized from a bytes object, io.BytesIO() now
Thanks for spotting, There is a new patch in http://bugs.python.org/issue22125 to fix the warnings. David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes-like objects
On Sun, Oct 05, 2014 at 11:32:08PM +0200, Victor Stinner wrote: > I'm not sure that the term has an unique definition. In some parts of > Python, I saw explicit checks on the type: bytes or bytearray, > sometimes memoryview is accepted. The behaviour is different in C > functions using PyArg API. It probably depends if the function relies > on the content (read bytes) or on methods (ex: call .find). Buffers aren't "bytes like" in that many of them aren't immutable, even when the buffer object itself is hashable. An example of this is the buffer exposed by mmap.mmap() with MAP_SHARED. This came up during the StringIO optimization changes a few months back, it seems some oversight in the original design that got carried through to Python 3. If we're approaching the topic of defining bytes-like things with improved rigor, it might be worth discussing. Making bytes-like objects an explicit thing in the language feels like solidifying what is mostly a CPython implementation detail. For example, at least until recently, PyPy emulated buffers in ways that often made them much slower to use than regular bytes. Another aspect is that the ability to twiddle bits derived from a buffer mostly implies that the code you are calling is going to always be written in C, or its future implementation will remain sufficiently restricted as to always accept buffers (perhaps by first copying them to bytes -- exactly what PyPy did until recently). +1 on improving the notion of bytes-like things in Python, but not necessarily by concretizing the existing interface. David > > Victor > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/dw%2Bpython-dev%40hmmz.org ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?
On Sun, Nov 23, 2014 at 07:39:30PM -0500, Donald Stufft wrote: > I don’t think this is really all that big of a deal. If we want to > move off of Github doing so is easy. There are lots of (not nearly as > good as but probably still better than what we have now) OSS software > that gives you a github like flow. The only *data* that is really in > there is what’s stored in the repository itself (since I don’t think > for anything major we’d ever put issues there or use the wiki) which > is trivial to move around. Assuming PRs are enabled on the new repo, how will that interact with patch review/the issue tracker? Is the goal here to replace the existing process wholesale in one step? It doesn't seem fair to say that moving to GitHub will be easy unless interrupting every contributor's flow is considered "free", or some Rietveld bridge script magically writes itself. The former impacts review bandwidth, the latter infrastructure bandwidth (which already seems quite contended, e.g. given the job board is still MIA). David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker reviews look like spam
SPF only covers the envelope sender, so it should be possible to set that to something that validates with SPF, keep the RFC822 From: header as it is, and maybe(?) include a separate Sender: header matching the envelope address. David On Tue, May 12, 2015 at 06:08:30PM -0400, Terry Reedy wrote: > Gmail dumps patch review email in my junk box. The problem seems to be the > spoofed From: header. > > Received: from psf.upfronthosting.co.za ([2a01:4f8:131:2480::3]) > by mx.google.com with ESMTP id > m1si26039166wjy.52.2015.05.12.00.20.38 > for ; > Tue, 12 May 2015 00:20:38 -0700 (PDT) > Received-SPF: softfail (google.com: domain of transitioning > [email protected] does not designate 2a01:4f8:131:2480::3 as permitted > sender) client-ip=2a01:4f8:131:2480::3; > > Tracker reviews are the only false positives in my junk list. Otherwise, I > might stop reviewing. Verizon does not even deliver mail that fails its junk > test, so I would not be surprised if there are people who simply do not get > emailed reviews. > > Tracker posts are sent from Person Name > Perhaps reviews could come 'from' Person Name > > Even direct tracker posts just get a neutral score. > Received-SPF: neutral (google.com: 2a01:4f8:131:2480::3 is neither permitted > nor denied by best guess record for domain of > [email protected]) client-ip=2a01:4f8:131:2480::3; > > SPF is Sender Policy Framework > https://en.wikipedia.org/wiki/Sender_Policy_Framework > > Checkins mail, for instance, gets an SPF 'pass' because python.org > designates mail.python.org as a permitted sender. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Counting references to Py_None
On Sun, Mar 20, 2016 at 01:43:27PM -0300, Facundo Batista wrote: > Hello! > > I'm seeing that our code increases the reference counting to Py_None, > and I find this a little strange: isn't Py_None eternal and will never > die? > > What's the point of counting its references? Avoiding a branch on every single Py_DECREF / Py_INCREF? > > Thanks! > > -- > .Facundo > > Blog: http://www.taniquetil.com.ar/plog/ > PyAr: http://www.python.org/ar/ > Twitter: @facundobatista > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/dw%2Bpython-dev%40hmmz.org ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)
On Tue, Apr 12, 2016 at 11:12:27PM +1000, Steven D'Aprano wrote: > I can think of one possible threat. Suppose that the locale library > has a bug, so that calling "aardvark".isdigit seg faults, potentially > executing arbitrary C code, but at the very least crashing the > application. Is that the sort of attack you're concerned by? This thread already covered the need to address SEGV at length. For a truly evil user, almost any kind of crash is an opportunity to take control of the system, and a security solution ignoring this is no security solution at all. > Maybe so. And then Jon will fix that vulnerability. And somebody will > find a new one. And he'll fix that too, or decide that it is too hard > to fix and give up. > > That's how security works. Even software designed for security can > have exploitable bugs: > > It seems unfair to me to hold Jon to a higher standard than we hold > people like Apple, or the Linux kernal devs. I don't believe that's what is happening here. In the OS analogy, Jon is generating busywork trying to secure an environment similar to Windows 3.1 that was simply never designed with e.g. memory protection in mind to begin with, and there is no evidence after numerous attempts spanning many years by multiple people that such an environment can be secured meaningfully while still remaining generally useful. > I fully accept and respect your personal opinion, based on your > experience, that Jon's tactic is doomed to failure. But if he needs to > learn this for himself, just as you had to learn it for yourself > (otherwise you wouldn't have started your own sandbox project), I can > respect that too. Progress depends on the unreasonable person who > thinks they can overturn the conventional wisdom. I'd deeply prefer it is this turned into an investigation or patchset making CPython work nicely with seccomp, sandbox(7), pledge(2) or whatever capability minimization mechanisms exist on Windows, they are all mechanisms to make it much safer for random code to be executing on your system, designed by folk who at all times expressively had security in mind. But that's not what's happening, instead a dead horse is being flogged over a hundred messages in our inboxes and IMHO it is excruciating to watch. > Even if the only thing we learn from Jon's experiment is a new set of > tricks for breaking out of the sandbox, that's still interesting, if > not useful. Don't forget the worst case: a fundamentally broken security module heavily marketed to the naive using claims the core team couldn't break it. David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Yearly PyPI breakage
This is mostly just observational, and not meant primarily as criticism of the fabulous work of Donald and others (ignoring pypa, also the prompt, reliable, and skilled support responses common on such places as IRC), however I can't help but notice that PyPI governance seems to come under fire vastly more often than similar and much more popular packaging systems, and some choices that have been made particularly in recent years have caused a noticeable amount of dissent with what might be considered the typical developer. When a contributor to the core language is having repeat issues maintaining some basic element of the function of the packaging system, might it be fair to reflect on how changes to those functions are being managed? There are PEPs covering a great deal of the work done to PyPI recently, but, and I say this as someone who has bumped into friction with the packaging tooling in the relatively recent past, even I despite my motivations to the contrary, I have not read most of them. It seems the current process is observed by few, does not sufficiently address the range of traditional use cases that were possible in the past, and the first the common user learns of a change is when pip (after insisting it must be upgraded) fails to function as it previously did. The usual course then is some complaint, that leads to distutils-sig, which ultimately leads to pointing at some design work that was only observed by perhaps 50 people max that turns out had some edge cases that hurt in a common use case. Is there something to contemplate in here? I dislike posting questions instead of answers, but it seems apparent there is a problem here and it continues to remain unaddressed. David On Tue, May 03, 2016 at 07:06:12PM +, Stefan Krah wrote: > > Hello, > > Could someone enlighten me which hoops I have to jump through > this year in order to keep pip downloads working? > > Collecting cdecimal > Could not find a version that satisfies the requirement cdecimal (from > versions: ) > No matching distribution found for cdecimal > You are using pip version 7.1.2, however version 8.1.1 is available. > You should consider upgrading via the 'pip install --upgrade pip' command. > > > If this continues, I'm going to release a premium version that's > 50% faster and only available from bytereef.org or Anaconda. > > > > Stefan Krah > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/dw%2Bpython-dev%40hmmz.org ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Yearly PyPI breakage
On Fri, May 06, 2016 at 12:03:48AM +, Brett Cannon wrote: > Is there something to contemplate in here? I dislike posting questions > instead of answers, but it seems apparent there is a problem here and it > continues to remain unaddressed. > This is whole thread is off-topic precisely because all of this is > discussed -- in the open -- on distutils-sig and decided there. If > people feel changes need to be made like broadcasting to a wider > audience when a change occurs, then please bring it up on > distutils-sig. I respectfully disagree, as this has been the default response applied for years, and it seems friction and dissemination have not been improved by it. Packaging is not some adjunct technicality, anyone learning Python in the past few years at least has been taught pip within the first week. > But if people choose not to participate then they are implicitly > delegating decision powers to those who do participate I believe this is also practically rhetorical in nature. I've watched the wars on distutils-sig for many years now, and the general strategy is that beyond minor outside influence, the process there is occupied by few individuals who are resistant to outside change. Outside influence is regularly met with essay-length reponses and tangential minutia until the energy of the challenge is expended. As an example, one common argument is that "Donald is overworked", however as an example, I offered a very long time ago to implement full text indexing for PyPI search. At the time I belive I was told such things weren't necessary, only to learn a few years later that Donald himself implemented the same function, and it suffers from huge latency and accuracy issues in the meantime. The solution to those problems is of course the ever-delayed rewrite. Over on distutils-sig, one will learn that a large amount of effort has been poured into a rewrite of PyPI (an effort going on years now), however the original codebase was not far from rescue (I had a local copy almost entirely ported to Flask in a few days). There is no reason why this effort nor any other (like full text search) should be used, as it often is, as an argument in the decisionmaking process that largely governs how PyPI and pip have worked in the recent years, yet it only takes a few glances at the archives to demonstrate that it regularly is. David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backport ssl.MemoryBIO on Python 2.7?
On Tue, May 23, 2017 at 06:13:17PM -0700, Cory Benfield wrote: > There are discussions around Requests unvendoring its dependencies > thanks to the improved nature of pip. This might be a year of pretty > big changes for Requests. In which case, what is to prevent Requests from just depending on pyOpenSSL as usual? I'm still writing 2.7 code every day and would love to see it live a little longer, but accepting every feature request seems the wrong way to go - and MemoryBIO is a hard sell as a security enhancement, it's new functionality. David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "Micro-optimisations can speed up CPython"
On Mon, May 29, 2017 at 07:27:05PM -0700, Guido van Rossum wrote: > Is the author of that article using non-standard terminology? The article > doesn't appear to be about __slots__ at all. They're referred to as slots throughout typeobject.c ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "Micro-optimisations can speed up CPython"
On Tue, May 30, 2017 at 09:38:55PM +0300, Serhiy Storchaka wrote: > > In early ages of C structures didn't create namespaces, and member > > names were globals. > >That's nonsense. The reason is greppability. > Good reason! The first time I heard about prefixing struct members was to allow tricks like this: x86_64-linux-gnu/bits/stat.h 94:# define st_atime st_atim.tv_sec /* Backward compatibility. */ 95:# define st_mtime st_mtim.tv_sec 96:# define st_ctime st_ctim.tv_sec Which is relatively safe thanks to the prefix. David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7
Hi Cory, On Thu, Jun 01, 2017 at 11:22:21AM +0100, Cory Benfield wrote: > We want to support as many TLS backends as possible. Just a wild idea, but have you investigated a pure-Python fallback for 2.7 such as TLSlite? Of course the fallback need only be used during bootstrapping, and the solution would be compatible with every stable LTS Linux distribution release that was not shipping the latest and greatest 2.7. David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7
On Thu, Jun 01, 2017 at 11:47:31AM +0100, Cory Benfield wrote: > I have, but discarded the idea. I'm glad to hear it was given sufficent thought. :) I have one final 'crazy' idea, and actually it does not seem to bad at all: can't you just fork a subprocess or spawn threads to handle the blocking SSL APIs? Sure it wouldn't be beautiful, but it is more appealing than forcing an upgrade on all 2.7 users just so they can continue to use pip. (Which, ironically, seems to resonate strongly with the motivation behind all of this work -- allowing users to continue with their old environments without forcing an upgrade to 3.x!) David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7
On Thu, Jun 01, 2017 at 12:18:48PM +0100, Cory Benfield wrote: > So, this will work, but at a performance and code cleanliness cost. > This essentially becomes a Python-2-only code-path, and a very large > and complex one at that. "Doctor, it hurts when I do this .." Fine, then how about rather than exporting pip's problems on to the rest of the world (which an API change to a security module in a stable branch most certainly is, 18 months later when every other Python library starts depending on it), just drop SSL entirely, it will almost certainly cost less pain in the long run, and you can even arrange for the same code to run in both major versions. Drop SSL? But that's madness! Serve the assets over plain HTTP and tack a signature somewhere alongside it, either side-by-side in a file, embedded in a URL query string, or whatever. Here[0] is 1000 lines of pure Python that can validate a public key signature over a hash of the asset as it's downloaded. Embed the 32 byte public key in the pip source and hey presto. [0] https://github.com/jfindlay/pure_pynacl/blob/master/pure_pynacl/tweetnacl.py Finding someone to audit the signature checking capabilities of [0] will have vastly lower net cost than getting the world into a situation where pip no longer runs on the >1e6 EC2 instances that will be running Ubuntu 14.04/16.04 LTS until the turn of the next decade. Requests can't be installed without a working SSL implementation? Then drop requests, it's not like it does much for pip anyway. Downloads worldwide get a huge speedup due to lack of TLS handshake latency, a million Squid caching reverse proxies worldwide jump into action caching tarballs they previously couldn't see, pip's _vendor directory drops by 4.2MB, and Python package security depends on 1k lines of memory-safe code rather than possibly *the* worst example of security-unconcious C to come into existence since the birth of our industry. Sounds like a win to me. Maybe set a standard rather than blindly follow everyone else, at the cost of.. everyone else. David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7
On Thu, Jun 01, 2017 at 04:01:54PM +0100, Cory Benfield wrote: > > lower net cost than getting the world into a situation where pip no > > longer runs on the >1e6 EC2 instances that will be running Ubuntu > > 14.04/16.04 LTS until the turn of the next decade. > So for the record I’m assuming most of the previous email was a joke: > certainly it’s not going to happen. ;) > But this is a real concern that does need to be addressed Unfortunately it wasn't, but at least I'm glad to have accidentally made a valid point amidst the cloud of caffeine-fuelled irritability :/ Apologies for the previous post, it was hardly constructive. David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7
On Sat, Jun 03, 2017 at 02:10:50AM +1000, Nick Coghlan wrote: > * and figure out some other pip-specific option for ensurepip > bootstrapping (like a *private* MemoryBIO implementation, or falling > back to synchronous mode in requests) Ignoring Ben's assertion regarding the legitimacy of async wrap_socket() (which seems to render this entire conversation moot), if you still really want to go this route, could ctypes be abused to provide the missing implementation from the underlying libs? It'd be a hack, but it would only be necessary during bootstrapping. David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Better HTTP 1.1 support in http.server?
On 24 September 2012 19:39, Christian Heimes wrote: > Am 24.09.2012 17:27, schrieb Antoine Pitrou: >> >> Hello, >> >> I was wondering if it would be worth providing better HTTP 1.1 support >> in http.server. The way I envision it, there would be a separate >> HTTP11RequestHandler which would provide: >> >> - a smart wfile with automatic chunk encoding (which relieves the API >> user from manually handling chunk encoding or content length >> calculation) >> - keep-alive enabled by default >> - HTTP 1.1 by default (BaseHTTPRequestHandler defaults to 1.0) >> >> What do you think? > > +1 for 3.4 > > You proposed gave me another idea. What do you think about SPDY support > in the stdlib? It's the next step after HTTP 1.1. Given the rate SPDY is changing, complexity of implementation, and that some prerequisites aren't in place (zlib module needs to support specifying the dictionary), this probably isn't a good idea right away. It's also easy to get a similar effect using a SPDY-capable reverse proxy. > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/dw%40botanicus.net ___ 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] PATCH/RFC for AF_NETLINK support
On Mon, Jan 10, 2005 at 05:17:49PM +0100, Philippe Biondi wrote: > I've done a small patch to use linux AF_NETLINK sockets (see below). > Please comment! As of 2.6.10, a very useful new netlink family was merged - NETLINK_KOBJECT_UEVENT. I'd imagine quite a lot of interest from Python developers for NETLINK support will come from this new interface in the coming years. http://lwn.net/Articles/101210/ http://lkml.org/lkml/2004/9/10/315 http://vrfy.org/projects/kevents/ http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.10 I would like to see (optional?) support for this before your patch is merged. I have a long-term interest in a Python-based service control / init replacement / system management application, for use in specialised environments. I could definately use this. :) Thanks, David. -- Harmless - and in its harmlessness, diabolical. -- The Mold Of Yancy (Philip K. Dick) ___ 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] PATCH/RFC for AF_NETLINK support
On Tue, Jan 11, 2005 at 02:15:23PM +, Jp Calderone wrote: > > I would like to see (optional?) support for this before your patch is > > merged. I have a long-term interest in a Python-based service control / > > init replacement / system management application, for use in specialised > > environments. I could definately use this. :) > > Useful indeed, but I'm not sure why basic NETLINK support should be > held up for it? Point taken. I don't recall why I thought special code would be required for this. I was thinking a little more about how support might be added for older kernels. No harm can be done by compiling in the constant, and it doesn't cost much. How about: #include ... #ifndef NETLINK_KOBJECT_UEVENT #define NETLINK_KOBJECT_UEVENT 15 #endif /* Code assuming build host supports KOBJECT_UEVENT. */ Type thing. Cheers, David. -- ... do you think I'm going to waste my time trying to pin physical interpretations upon every optical illusion of our instruments? Since when is the evidence of our senses any match for the clear light of reason? -- Cutie, in Asimov's Reason ___ 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] Simple CPython stack overflow.
Just noticed this and wondered if it came under the Python should never
crash mantra. Should sys.getrecursionlimit() perhaps be taken into
account somewhere?
>>> D = {'a': None}
>>> for i in xrange(15):
... D = {'a': D}
...
>>> D
{'a': {'a': {'a': {'a': {'a': {'a': {'a': {'a': {'a': {'a': {'a':
{'a': {'a': {'a': {'a': {'a': {'a': {'a': ': {'a': {'a': {'a':
{'a': {'a': {'a': {'a': {[+]'a': {'a': {'a': {'a': {'a': {'a': {'a':
{'a': {'a' Bus error
bash$
Cheers,
David.
--
'tis better to be silent and be thought a fool,
than to speak and remove all doubt.
-- Lincoln
___
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] dev listinfo page (was: Re: Python + Ping)
Hello, Would it perhaps be an idea, given the number of users posting to the dev list, to put a rather obvious warning on the listinfo page: http://mail.python.org/mailman/listinfo/python-dev Something like Do not post general Python questions to this list! For help with Python please see the Python help page! David. ___ 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] [EMAIL PROTECTED] failing sender verification.
Hi there, Recently, updates from MoinMoin have started getting quarantined due to sender verification failing. On investigating the problem, it seems that an assumption about the webmaster mailbox is incorrect: 220 bag.python.org ESMTP Postfix (Debian/GNU) MAIL FROM: <> 503 Error: send HELO/EHLO first HELO argon.maildefence.co.uk 250 bag.python.org MAIL FROM: <> 250 Ok RCPT TO: [EMAIL PROTECTED] 553 invalid bounce (address does not send mail) The MoinMoin instance on Python.org is sending mail as "[EMAIL PROTECTED]". Can somebody take a look? Or at least tell me who to contact. Thanks, David. PS: Please CC me in replies as I am not currently subscribed. -- It's never too late to have a happy childhood. ___ 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] syntactic support for sets
On Wed, Feb 01, 2006 at 03:03:22PM -0500, Phillip J. Eby wrote: > The only case that looks slightly less than optimal is: > > set((1, 2, 3, 4, 5)) > > But I'm not sure that it warrants a special syntax just to get rid of the > extra (). In any case I don't think it's possible to differentiate between the current calling convention and the 'parenless' one reliably, eg.: S = set([]) There is no way to tell if that is a set containing an empty list created using the parenless syntax, or an empty set, as is created with the current calling convention. -- DISOBEY, v.t. To celebrate with an appropriate ceremony the maturity of a command. ___ 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
