Re: [Python-Dev] datetime nanosecond support (ctd?)

2014-12-11 Thread Marko Rauhamaa
Ethan Furman : > On 12/11/2014 11:14 AM, Guido van Rossum wrote: >> (I wouldn't be surprised if there wasn't -- while computer clocks >> have a precision in nanoseconds, that doesn't mean they are that >> *accurate* at all (even with ntpd running). > > The real-world use cases deal with getting th

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

2014-12-16 Thread Marko Rauhamaa
Mark Roberts : > it's outright insulting to be told my complaints about writing 2/3 > compatible code are invalid on the basis of "premature optimization". IMO, you should consider forking your library code for Python2 and Python3. The multidialect code will look unidiomatic for each dialect. Whe

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

2014-12-16 Thread Marko Rauhamaa
Brian Curtin : > I'm a few inches shorter than Brett, but having done several sizable > ports, dual-source has never even on the table. I would prefer the > "run 2to3 at installation time" option before maintaining two versions > (which I do not prefer at all in reality). How about "run 3to2 at i

Re: [Python-Dev] PEP 471 (scandir): Add a new DirEntry.inode() method?

2015-02-14 Thread Marko Rauhamaa
Antoine Pitrou : > The whole point of scandir is to expose low-level system calls in a > cross-platform way. Cross-platform is great and preferable, but low-level system facilities should be made available even when they are unique to a particular OS. Marko _

[Python-Dev] collections.sortedtree

2014-03-26 Thread Marko Rauhamaa
I have made a full implementation of a balanced tree and would like to know what the process is to have it considered for inclusion in Python 3. To summarize, the implementation closely parallels dict() features and resides in _collectionsmodule.c under the name collections.sortedtree. It uses so

Re: [Python-Dev] collections.sortedtree

2014-03-26 Thread Marko Rauhamaa
Guido van Rossum : > Actually, the first step is publish it on PyPI, the second is to get a > fair number of happy users there. The bar for getting something > included into the stdlib is pretty high -- you need to demonstrate > that there is a need *and* that having it as a 3rd party module is a

Re: [Python-Dev] collections.sortedtree

2014-03-26 Thread Marko Rauhamaa
Antoine Pitrou : > Wouldn't a heapq work as well for those two? In my experience, networking entities typically start a timer at each interaction and cancel the pending one. So you have numerous timers that virtually never expire. You might have 100 interactions per second, each canceling and res

Re: [Python-Dev] collections.sortedtree

2014-03-26 Thread Marko Rauhamaa
Terry Reedy : > Perhaps the collections doc should mention that there are other > specializes container types available on PyPI and either list some or > point to a wiki page listing some. There must be at least 10 that > could be included in such a list. There *is* a relatively high threshold of

Re: [Python-Dev] collections.sortedtree

2014-03-26 Thread Marko Rauhamaa
Antoine Pitrou : > Marko Rauhamaa wrote: >> In my experience, networking entities typically start a timer at each >> interaction and cancel the pending one. So you have numerous timers >> that virtually never expire. You might have 100 interactions per >> second, each

Re: [Python-Dev] collections.sortedtree

2014-03-26 Thread Marko Rauhamaa
Dan Stromberg : > It'd likely make sense to have either a pure python implementation, or > pure python and C-extended, so that Pypy and Jython can share the > feature with CPython. Jython can build directly on Java's native SortedMap implementation. The API should not tie it to a tree. Optimizati

Re: [Python-Dev] collections.sortedtree

2014-03-27 Thread Marko Rauhamaa
Thomas Wouters : > Not to mention discussion about whether it shouldn't just be an existing > PyPI package, like http://pypi.python.org/pypi/blist, rather than a new > implementation. I'm fine with any implementation as long as it is in the standard library. Marko __

Re: [Python-Dev] collections.sortedtree

2014-03-28 Thread Marko Rauhamaa
Raymond Hettinger : > * An AVL balanced tree isn't the only solution or necessarily the best > solution to the problem. Tree nodes tend to take more space than > denser structures and they have awful cache locality (these are the > same reasons that deques use doubly-linked blocks rather than a pl

Re: [Python-Dev] Negative timedelta strings

2014-03-28 Thread Marko Rauhamaa
Greg Ewing : > ISO 8601 doesn't seem to define a representation for > negative durations, though, so it wouldn't solve the > original problem. XSD uses ISO 8601 durations and allows a sign before the initial "P". It would appear PT1M means 60 or 61 seconds. P1D means 23, 24 or 25 hours. P1M mean

Re: [Python-Dev] collections.sortedtree

2014-03-28 Thread Marko Rauhamaa
Marko Rauhamaa : > For example, Jython would probably use SortedTree to implement it. That word just keeps coming out of my keyboard. The Java class is of course the TreeMap. Marko ___ Python-Dev mailing list Python-Dev@python.org ht

Re: [Python-Dev] collections.sortedtree

2014-03-30 Thread Marko Rauhamaa
Guido van Rossum : > Yeah, so the pyftp fix is to keep track of how many timers were > cancelled, and if the number exceeds a threshold it just recreates the > heap, something like > > heap = [x for x in heap if not x.cancelled] > heapify(heap) I measured my target use case with a simple emulatio

Re: [Python-Dev] == on object tests identity in 3.x - list delegation to members?

2014-07-13 Thread Marko Rauhamaa
Nick Coghlan : > Right, it's not a mere optimisation - it's the only way to get > containers to behave sensibly. Otherwise we'd end up with nonsense > like: > x = float("nan") x in [x] > False Why is that nonsense? I mean, why is it any more nonsense than >>> x == x False Anyway

Re: [Python-Dev] Multiline with statement line continuation

2014-08-16 Thread Marko Rauhamaa
Steven D'Aprano : > I simply don't care. They will try it, discover that tuples are not > context managers, fix their code, and move on. *Could* tuples (and lists and sequences) be context managers? *Should* tuples (and lists and sequences) be context managers? > I don't think that some vague

Re: [Python-Dev] Bytes path support

2014-08-19 Thread Marko Rauhamaa
Tres Seaver : > On 08/19/2014 01:43 PM, Ben Hoyt wrote: >> Fair enough. I don't quite understand, though -- why is the "official >> policy" to kill something that's "essential" on *nix? > > ISTM that the policy is based on a fantasy that "it looks like text to > me in my use cases, so therefore it

Re: [Python-Dev] Bytes path support

2014-08-19 Thread Marko Rauhamaa
Guido van Rossum : > With my serious hat on, I would like to claim that *conceptually* > filenames are most definitely text. Due to various historical > accidents the UNIX system calls often encoded text as arguments, and > we sometimes need to control that encoding. Due to historical accidents,

Re: [Python-Dev] Bytes path support

2014-08-21 Thread Marko Rauhamaa
"Martin v. Löwis" : > I think the people defending the "Unix file names are just bytes" side > often miss an important detail: displaying file names to the user, and > allowing the user to enter file names. The user interface is a real issue and needs to be addressed. It is separate from the OS i

Re: [Python-Dev] Bytes path support

2014-08-21 Thread Marko Rauhamaa
Nick Coghlan : > Python 3 says it's *our* problem to deal with on behalf of our > developers. http://www.imdb.com/title/tt0120623/quotes?item=qt0353406> Flik: I was just trying to help. Mr. Soil: Then help us; *don't* help us. Marko ___ Pyth

Re: [Python-Dev] Bytes path support

2014-08-23 Thread Marko Rauhamaa
"Stephen J. Turnbull" : > Just read as bytes and decode piecewise in one way or another. For > Oleg's HTML case, there's a well-understood structure that can be used > to determine retry points HTML and XML are interesting examples since their encoding is initially unknown:

Re: [Python-Dev] Bytes path support

2014-08-23 Thread Marko Rauhamaa
Isaac Morland : >> HTTP/1.1 200 OK >> Content-Type: text/html; charset=ISO-8859-1 >> >> >> >> >> > > For HTML it's not quite so bad. According to the HTML 4 standard: > [...] > > The Content-Type header takes precedence over a element. I > thought I read once that the reason was to all

Re: [Python-Dev] Bytes path support

2014-08-23 Thread Marko Rauhamaa
"R. David Murray" : > The same problem existed in python2 if your goal was to produce a stream > with a consistent encoding, but now python3 treats that as an error. I have a different interpretation of the situation: as a rule, use byte strings in Python3. Text strings are a special corner case

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

2014-08-30 Thread Marko Rauhamaa
Paul Moore : > Cool, in which case this sounds like a good plan. I have no particular > opinion on whether there should be a global Python-level "don't check > certificates" option, but I would suggest that the docs include a > section explaining how a user can implement a > "--no-check-certificat

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

2014-08-31 Thread Marko Rauhamaa
Victor Stinner : > Proposition > === > > If a system call fails with ``EINTR``, Python must call signal > handlers: call ``PyErr_CheckSignals()``. If a signal handler raises > an exception, the Python function fails with the exception. > Otherwise, the system call is retried. If the syste

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

2014-08-31 Thread Marko Rauhamaa
Victor Stinner : > Sorry but I don't understand your remark. What is your problem with > retrying syscall on EINTR? The application will often want the EINTR return (exception) instead of having the function resume on its own. > Can you please elaborate? What do you mean by "get wrong"? Proper

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

2014-08-31 Thread Marko Rauhamaa
Victor Stinner : > But I don't get you point. How does this PEP make the situation worse? Did I say it would? I just wanted to make sure the system call resumption doesn't become mandatory. Haven't thought through what the exception raising technique would entail. It might be perfectly ok apart

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

2014-08-31 Thread Marko Rauhamaa
Ethan Furman : > On 08/31/2014 02:19 PM, Marko Rauhamaa wrote: >> The application will often want the EINTR return (exception) instead >> of having the function resume on its own. > > Examples? > > As an ignorant person in this area, I do not know why I would ever

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

2014-08-31 Thread Marko Rauhamaa
"R. David Murray" : > PS: I recently switched from using selectors to using a timeout on a > socket because in that particular application I could, and because > reading a socket with a timeout handles EINTR (in recent python > versions), whereas reading a non-blocking socket doesn't. Under the >

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

2014-09-01 Thread Marko Rauhamaa
Victor Stinner : > No, it's the opposite. The PEP doesn't change the default behaviour of > SIGINT: CTRL+C always interrupt the program. Which raises an interesting question: what happens to the os.read() return value if SIGINT is received? Marko ___

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

2014-09-01 Thread Marko Rauhamaa
Charles-François Natali : >> Which raises an interesting question: what happens to the os.read() >> return value if SIGINT is received? > > There's no return value, a KeywordInterrupt exception is raised. > The PEP wouldn't change this behavior. Slightly disconcerting... but I'm sure overriding S

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

2014-09-01 Thread Marko Rauhamaa
"R. David Murray" : > Windows. Enough said? > [...] > This should tell you just about everything you need to know about why > we want to fix this problem so that things work cross platform. I feel your pain. Well, not really; I just don't want my linux bliss to be taken away. Marko ___

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

2014-09-01 Thread Marko Rauhamaa
"R. David Murray" : > On Mon, 01 Sep 2014 14:15:52 +0300, Marko Rauhamaa wrote: >> * Allow the application to react to signals immediately in the main >>flow. > > You don't want to be writing your code in Python then. In Python you > *never* g

Re: [Python-Dev] PEP 394 - Clarification of what "python" command should invoke

2014-09-19 Thread Marko Rauhamaa
Donald Stufft : > My biggest problem with ``python3``, is what happens after 3.9. I know > Guido doesn’t particularly like two digit version numbers and it’s > been suggested on this list that instead of 3.10 we’re likely to move > directly into 4.0 regardless of if it’s a “big” change or not. py

Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX

2014-09-25 Thread Marko Rauhamaa
Steven D'Aprano : > Perhaps I'm missing something, but aren't there easier ways to attack > os.system than the bash env vulnerability? The main concern is the cases where you provide a service accessible through an SSH login and try to sandbox the client with limited functionality. SSH passes so