Re: [Python-Dev] return type of __complex__
Stephen J. Turnbull wrote: It's a design bug, yes. The question is, does it conform to documented behavior? The 2.7 docs say this about __complex__: Called to implement the built-in function complex() ... Should return a value of the appropriate type. So the question is whether float is an "appropriate type" when you're expecting a complex. -- Greg ___ 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] return type of __complex__
Antonio Cuni wrote: Traceback (most recent call last): File "", line 1, in TypeError: __complex__ should return a complex object i.e., the complex constructor does not check that __complex__ returns an actual complex, while the cmath functions do. Looks to me like cmath is being excessively finicky here. Why shouldn't a float be usable in *any* context expecting a complex? -- Greg ___ 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] Memoryviews should expose the underlying memory address
Nick Coghlan wrote: I'm fine with exposing a memoryview.buffer_address attribute in 3.4. What about objects whose buffer address can change when the buffer isn't locked? -- Greg ___ 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] CFFI released
Is there any provision for keeping the compiled C code and distributing it along with an application? Requiring a C compiler to be present at all times could be a difficulty for Windows. -- Greg ___ 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] Issue 2736: datetimes and Unix timestamps
Terry Reedy wrote: "A rich comparison method may return the singleton NotImplemented if it does not implement the operation for a given pair of arguments. By convention, False and True are returned for a successful comparison. However, these methods can return any value," That's to give the other operand a chance to handle the operation. If they both return NotImplemented, then a TypeError is raised by the interpreter. -- Greg ___ 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] TZ-aware local time
Alexander Belopolsky wrote: The problem is again the DST ambiguity. One day a year, datetime(y, m, d, 1, 30, tzinfo=Local) represents two different times and another day it represents no valid time. The documentation example (fixed in issue 9063) addresses the ambiguity by defaulting to standard time, but it does this at a cost of having no way to spell "the other hour." What would be so bad about giving datetime objects a DST flag? Apps that don't care could ignore it and get results no worse than the status quo. -- Greg ___ 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] [Python-checkins] peps: Add PEP 422: Dynamic Class Decorators
PJ Eby wrote: At the least, if they're not going to be in decorator order, the member shouldn't be called "__decorators__". ;-) Obviously it should be called __srotaroced__. -- Greg ___ 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] C-level duck typing
On 17/05/12 12:17, Robert Bradshaw wrote: This is exactly what was proposed to start this thread (with minimal collusion to avoid conflicts, specifically partitioning up a global ID space). Yes, but I think this part of the mechanism needs to be spelled out in more detail, perhaps in the form of a draft PEP. Then there will be something concrete to discuss in python-dev. -- Greg ___ 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] C-level duck typing
Dag wrote: I'm not asking you to consider the details of all that. Just to allow some kind of high-performance extensibility of PyTypeObject, so that we can *stop* bothering python-dev with specific requirements from our parallel universe of nearly-all-Cython-and-Fortran-and-C++ codebases :-) Maybe you should ask for a bit more than that. Tp_flags bits are a scarce resource, and they shouldn't be handed out lightly to anyone who asks for one. Eventually they're going to run out, and then something else will have to be done to make further extensions of the type object possible. So maybe it's worth thinking about making a general mechanism available for third parties to extend the type object without them all needing to have their own tp_flags bits and without needing to collude with each other to avoid conflicts. -- Greg ___ 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] Adding types.build_class for 3.3
Nick Coghlan wrote: On Thu, May 10, 2012 at 10:03 AM, Greg Ewing wrote: Something should only go in a class namespace if it somehow relates to that particular class, and other classes could might implement it differently. That's not the case with build_class(). Not true - you *will* get a type instance out of any sane call to type.define(). You must have misunderstood me, because this doesn't relate to the point I was making at all. What I'm trying to say is that I don't see the justification for making build_class() a static method rather than a plain module-level function. To my way of thinking, static methods are very rarely justified in Python. The only argument so far in this case seems to be "we can't make up our minds where else to put it", which is rather lame. A stronger argument would be if there were cases where you wanted to define a subclass of type that implemented build_class differently. But how would it get called, if everyone who uses build_class invokes it using 'type.build_class()'? -- Greg ___ 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] Adding types.build_class for 3.3
Nick Coghlan wrote: In that case, consider me convinced: static method it is. -0.93. Static methods are generally unpythonic, IMO. Python is not Java -- we have modules. Something should only go in a class namespace if it somehow relates to that particular class, and other classes could might implement it differently. That's not the case with build_class(). -- Greg ___ 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] [Python-checkins] cpython: Issue #14716: Change integer overflow check in unicode_writer_prepare()
Mark Dickinson wrote: Is the gain from this kind of micro-optimization really worth the cost of replacing obviously correct code with code whose correctness needs several minutes of thought? The original code isn't all that obviously correct to me either. I would need convincing that the arithmetic being used to check for overflow can't itself suffer from overflow. At least that much is obvious from the new version. -- Greg ___ 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] Adding types.build_class for 3.3
Nick Coghlan wrote: Instead, I'm now thinking we should add a _types C extension module and expose the new function as types.build_class(). I don't want to add an entire new module just for this feature, and the types module seems like an appropriate home for it. Dunno. Currently the only thing the types module contains is types. A function would seem a bit out of place there. I don't think there's too much wrong with putting it in the operators module -- it's a function doing something that is otherwise expressed by special syntax. -- Greg ___ 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] [Python-checkins] cpython: Issue #14127: Add ns= parameter to utime, futimes, and lutimes.
Larry Hastings wrote:
On 05/03/2012 10:07 PM, Benjamin Peterson wrote:
+if (times && ns) {
+PyErr_Format(PyExc_RuntimeError,
Why not a ValueError or TypeError?
Well it's certainly not a TypeError.
TypeError is not just for values of the wrong type,
it's also used for passing the wrong number of arguments
to a function and the like. So TypeError would be a
reasonable choice here, I think.
--
Greg
___
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] Cython for cPickle?
Alexandre Vassalotti wrote: We have custom stack and dictionary implementations just for the sake of speed. We also have fast paths for I/O operations and function calls. All of that could very likely be carried over almost unchanged into a Cython version. I don't see why it should take multiple months. It's not a matter of rewriting it from scratch, just translating it from one dialect (C) to another (the C subset of Cython). -- Greg ___ 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] cpython: Fix email post-commit review comments.
On 19/04/12 11:22, Tres Seaver wrote: Maybe we should mandate that their names end with '_rtfm'. +1 -- Greg ___ 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] cpython: Fix email post-commit review comments.
Antoine Pitrou wrote: (and here we see why reference-stealing APIs are a nuisance: because you never know in advance whether a function will steal a reference or not, and you have to read the docs for each and every C API call you make) Fortunately, they're very rare, so you don't encounter them often. Unfortunately, they're very rare, so you're all the more likely to forget about them and get bitten. Functions with ref-stealing APIs really ought to have a naming convention that makes them stand out and remind you to consult the documentation. -- Greg ___ 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] Change to yield-from implementation
Mark Shannon wrote: We have recently removed the f_yieldfrom field from the frame object. (http://bugs.python.org/issue14230) Hey, wait a minute. Did anyone consider the performance effect of that change on deeply nested yield-froms? The way it was, a yield-from chain was traversed by a very tight C loop that found the end frame and resumed it directly. If I understand what you've done correctly, now it has to enter and execute a bytecode in every frame along the way. -- Greg ___ 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] PEP 418 is too divisive and confusing and should be postponed
Steven D'Aprano wrote: Greg Ewing wrote: the important thing about a clock that it *keeps going forward* That would be a *strictly* monotonic clock, as opposed to merely monotonic. Well, yes, but even that's not enough -- it needs to go forward at a reasonably constant rate, otherwise it's just as useless. If it had enough resolution, it could go forward by one femtosecond every hour for a while and still call itself strictly monotonic... -- Greg ___ 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] PEP 418 is too divisive and confusing and should be postponed
Cameron Simpson wrote: I maintain that "monotonic" still means what I said, and that it is the combination of the word with "clock" that brings in your other criteria. I'm not trying to redefine the word "monotonic" in general. All I'm saying is that *if* the PEP is going to talk about a "monotonic clock" or "monotonic time", it should clearly define what this means, because it's not obvious to everyone that it implies something more than the mathematical meaning. Alternatively, don't use the word "monotonic" at all, and find a better term. CLOCK_MONOTONIC Clock that cannot be set and represents monotonic time since some unspecified starting point. Which doesn't help very much, because it talks about "monotonic time" without saying what that means. Googling for that phrase doesn't seem turn up anything very useful. Apparently we're supposed to just know. -- Greg ___ 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] PEP 418 is too divisive and confusing and should be postponed
Cameron Simpson wrote: A monotonic clock never returns t0 > t1 for t0, t1 being two adjacent polls of the clock. On its own it says nothing about steadiness or correlation with real world time. No, no, no. This is the strict mathematical meaning of the word "monotonic", but the way it's used in relation to OS clocks, it seems to mean rather more than that. A clock whose only guarantee is that it never goes backwards is next to useless. For things like benchmarks and timeouts, the important thing about a clock that it *keeps going forward* at a reasonably constant rate. On the other hand, it can have an arbitrary starting point and doesn't have to be related to any external time standard. I'm assuming this is what Linux et al mean when they talk about a "monotonic clock", because anything else doesn't make sense. So if we're going to use the term "monotonic" at all, I think we should explicitly define it as having this meaning, i.e. both mathematically monotonic and steady. Failure to be clear about this has caused a huge amount of confusion in this thead so far. -- Greg ___ 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] PEP 418 is too divisive and confusing and should be postponed
Lennart Regebro wrote: Since the only monotonic clock that can be adjusted by NTP is Linux' CLOCK_MONOTONIC, if we avoid it, then time.monotonic() would always give a clock that isn't adjusted by NTP. I thought we decided that NTP adjustment isn't an issue, because it's always gradual. -- Greg ___ 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] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)
Cameron Simpson wrote: People have been saying "hires" throughout the threads I think, but I for one would be slightly happier with "highres". hirez? -- Greg ___ 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] Playing with a new theme for the docs, iteration 2
Steven D'Aprano wrote: While I sympathize with the ideal of making the docs readable, particular for those of us who don't have 20-20 vision, "must be readable from halfway across the room" is setting the bar too high. The point is that reducing contrast never makes anything more readable, and under some conditions it makes things less readable. So the only reason for using less than the maximum available contrast is aesthetics, and whether grey-on-white looks any nicer than black-on-white is very much a matter of opinion. In any case, the aesthetic difference is a very minor one, and you have to ask whether it's really worth compromising on contrast. If I'm reading the CSS correctly, the standard font used in the new docs is Lucinda Grande, with a fallback of Arial. Unfortunately, Lucinda Grande is normally only available on the Apple Mac, and Arial is a notoriously poor choice for on-screen text This seems to be another case of the designer over-specifying things. The page should just specify a sans-serif font and let the browser choose the best one available. Or not specify a font at all and leave it up to the user whether he wants serif or sans-serif for the body text -- some people have already said here that they prefer serif. -- Greg ___ 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] Playing with a new theme for the docs
PJ Eby wrote: Weird - I have the exact *opposite* problem, where I have to resize my window because somebody *didn't* set their text max-width sanely (to a reasonable value based on ems instead of pixels), and I have nearly 1920 pixels of raw text spanning my screen. If you don't want 1920-pixel-wide text, why make your browser window that large? -- Greg ___ 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] Playing with a new theme for the docs
Glyph Lefkowitz wrote: "do I have to resize my browser every time I visit a new site to get a decent width for reading". If all sites left the width to the browser, then I would be able to make my browser window a width that is comfortable for me with my chosen font size and leave it that way. The only time a site forces me to resize my window is when it thinks it has a better idea than me how wide the text should be. I prefer sites that don't try to control the layout of everything. When using a site that leaves most of it up to my browser, I never find myself wishing that the designer had specified something more tightly. However, I do often find myself wishing that the designer *hadn't* overridden the width, or the font size, or the text colour, or decided that I shouldn't be allowed to know whether I've visited links before, etc. etc. A web page is not a printed page. It is not rendered at a fixed size and viewed in its entirety at once. It needs to be flexible, able to be rendered in whatever size space is available or the user wants to devote to it. Browsers are very good at doing that -- unless the designer defeats them by fixing something that is better left flexible. -- Greg ___ 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] Playing with a new theme for the docs
Can we please get rid of the sidebar, or at least provide a way of turning it off? I don't think it's anywhere near useful enough to be worth the space it takes up. You can only use it when you're scrolled to the top of the page, otherwise it's just a useless empty space. Also, I often want to put the documentation side by side with the code I'm working on, and having about a quarter to a third of the horizontal space taken up with junk makes that much more awkward than it needs to be. A table of contents as a separate page is a lot more usable for me. I can keep it open in a browser tab and switch to it when I want to look at it. Most of the time I don't want to look at it and don't want it taking up space on the page. Also I agree about the grey text being suboptimal. Deliberately throwing away contrast, especially for the main body text, is insane. -- Greg ___ 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] Playing with a new theme for the docs
Ned Batchelder wrote: Any of the tweaks people are suggesting could be applied individually using this technique. We could just as easily choose to make the site left-justified, and let the full-justification fans use custom stylesheets to get it. Is it really necessary for the site to specify the justification at all? Why not leave it to the browser and whatever customisation the user chooses to make? -- Greg ___ 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] Python install layout and the PATH on win32
R. David Murray wrote: My understanding, though, is that Python does make a distinction between a system install of Python and a per-user one, so I don't think your objection really applies. Seems to me that for Python at least, the important distinction is not so much where the files are placed, but whether the registry entries are made machine-wide or user-local. -- Greg ___ 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] PEP czar for PEP 3144?
Guido van Rossum wrote: I personally like having 'iter' in the name (e.g. iterkeys() -- note that we dropped this in Py3k because it's no longer an iterator, it's a dict view now. But I don't want to promote that style for ipaddr.py. +1 from me too on having all methods that return iterators clearly indicating so. It's an important distinction, and it can be very confusing if some methods of an API return iterators and others don't with no easy way of remembering which is which. -- Greg ___ 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] Sandboxing Python
Armin Rigo wrote: For example, let's assume we can decref a object to 0 before its last usage, at address x. All you need is the skills and luck to arrange that the memory at x becomes occupied by a new bigger string object allocated at "x - small_number". That's a lot of assumptions. When you claimed that *any* segfault bug could be turned into an arbitrary-code exploit, it sounded like you had a provably general procedure in mind for doing so, but it seems not. In any case, I think Victor is right to object to his sandbox being shot down on such grounds. The same thing equally applies to any method of sandboxing any computation, whether it involves Python or not. Even if you fork a separate process running code written in Befunge, it could be prone to this kind of attack if there is a bug in it. What you seem to be saying is "Python cannot be sandboxed, because any code can have bugs." Or, "Nothing is ever 100% secure, because the universe is not perfect." Which is true, but not in a very interesting way. -- Greg ___ 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] Sandboxing Python
Mark Shannon wrote: You can't solve the too much time, without solving the halting problem, but you can make sure all code is interruptable (i.e. Cntrl-C works). If you can arrange for Ctrl-C to interrupt the process cleanly, then (at least on Unix) you can arrange to receive a signal after a timeout and recover cleanly from that as well.. -- Greg ___ 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] Sandboxing Python
Maciej Fijalkowski wrote: Segfaults (most of them) can generally be made into arbitrary code execution, Can you give an example of how this can be done? -- Greg ___ 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] slice subscripts for sequences and mappings
Thomas Wouters wrote: Why even have separate tp_as_sequence and tp_as_mapping anymore? That particular distinction never existed for Python types, so why should it exist for C types at all? I forget if there was ever a real point to it, I imagine the original motivation was to provide a fast path for types that take ints as indexes. Also, it dates from the very beginnings of Python, before it had user defined classes. At that time the archetypal sequence (list) and the archetypal mapping (dict) were very distinct -- I don't think dicts supported 'in' then, so there was no overlap. It looks like a case of "it seemed like a good idea at the time". The distinction broke down fairly soon after, but it's so embedded in the extension module API that it's been very hard to get rid of. -- Greg ___ 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] PEP 414
Nick Coghlan wrote: Armin's straw poll was actually about whether or not people used the future import for division, rather than unicode literals. It is indeed the same problem There are differences, though. Personally I'm very glad of the division import -- it's the only thing that keeps me sane when using floats. The alternative is not only butt-ugly but imposes an annoying performance penalty. I don't mind occasionally needing to glance at the top of a module in order to get the benefits. On the other hand, it's not much of a burden to put 'u' in front of string literals, and there is no performance difference. -- Greg ___ 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] State of PEP-3118 (memoryview part)
Stefan Krah wrote: Options 2) and 3) would ideally entail one backwards incompatible bugfix: In 2.7 and 3.2 assignment to a memoryview with format 'B' rejects integers but accepts byte objects, but according to the struct syntax mandated by the PEP it should be the other way round. Maybe a compromise could be made to accept both in the backport? That would avoid breaking old code while allowing code that does the right thing to work. -- Greg ___ 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] PEP 410 (Decimal timestamp): the implementation is ready for a review
Guido van Rossum wrote: if there is an *actual* causal link between file A and B, the difference in timestamps should always be much larger than 100 ns. And if there isn't a causal link, simultaneity is relative anyway. To Fred sitting at his computer, file A might have been created before file B, but to George running from the other end of the building in response to an urgent bug report, it could be the other way around. So to be *really* accurate, the API needs a way for the caller to indicate a frame of reference. -- Greg ___ 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] PEP 410 (Decimal timestamp): the implementation is ready for a review
On 16/02/12 06:43, Guido van Rossum wrote: This does not explain why microseconds aren't good enough. It seems none of the clocks involved can actually measure even relative time intervals more accurate than 100ns, and I expect that kernels don't actually keep their clock more accurate than milliseconds. I gather that modern x86 CPUs have a counter that keeps track of time down to a nanosecond or so by counting clock cycles. In principle it seems like a kernel should be able to make use of it in conjunction with other timekeeping hardware to produce nanosecond-resolution timestamps. Whether any existing kernel actually does that is another matter. It probably isn't worth the bother for things like file timestamps, where the time taken to execute the system call that modifies the file is likely to be several orders of magnitude larger. Until we have computers with terahertz clocks and gigahertz disk drives, it seems like a rather theoretical issue. And it doesn't look like Mr. Moore is going to give us anything like that any time soon. -- Greg ___ 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] Coroutines and PEP 380
Glyph wrote: Yes, but you /can/ look at a 'yield' and conclude that you /might/ need a lock, and that you have to think about it. My concern is that you will end up with vastly more 'yield from's than places that require locks, so most of them are just noise. If you bite your nails over whether a lock is needed every time you see one, they will cause you a lot more anxiety than they alleviate. Sometimes there's no alternative, but wherever I can, I avoid thinking, especially hard thinking. This maxim has served me very well throughout my programming career ;-). There are already well-known techniques for dealing with concurrency that minimise the amount of hard thinking required. You devise some well-behaved abstractions, such as queues, and put all your hard thinking into implementing them. Then you build the rest of your code around those abstractions. That way you don't have to rely on crutches such as explicitly marking everything that might cause a task switch, because it doesn't matter. -- Greg ___ 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] Potential NULL pointer dereference in descrobject.c
Matt Joiner wrote: ಠ_ಠ What's up with these ?_? messages? -- Greg ___ 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] A new dict for Xmas?
Mark Shannon wrote: I have a new dict implementation which allows sharing of keys between objects of the same class. We already have the __slots__ mechanism for memory savings. Have you done any comparisons with that? Seems to me that __slots__ ought to save even more memory, since it eliminates the per-instance dict altogether rather than just the keys half of it. -- Greg ___ 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] [SPAM: 3.000] [issue11682] PEP 380 reference implementation for 3.3
On 10/11/11 14:50, Nick Coghlan wrote: I'd actually be amenable to making it legal to omit the extra parentheses for both yield& yield from in the single argument case where there's no ambiguity... > The way your patch tried to do it also allowed "f(yield from x, 1)" which strikes me as being far too confusing Since 'yield from' is intended mainly for delegating to another generator, the 'x' there will usually be a function call, so you'll be looking at something like f(yield from g(x), 1) which doesn't look very confusing to me, but maybe I'm not impartial enough to judge. In any case, I'm now pursuing cofunctions as a better way of doing lightweight threading, so this issue probably doesn't matter so much. -- Greg ___ 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] [SPAM: 3.000] [issue11682] PEP 380 reference implementation for 3.3
On 10/11/11 11:43, Tim Delaney wrote: We have precedent for being more restrictive initially, and relaxing those restrictions later. I suggest that the more restrictive implementation go in now so that people can start playing with it. If the discussion comes to a consensus on more relaxed syntax, that can be added later (either in 3.3 or a later release). That's fair enough. I'll shut up now. -- Greg ___ 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] [SPAM: 3.000] [issue11682] PEP 380 reference implementation for 3.3
On 10/11/11 12:11, Guido van Rossum wrote: Actually it is valid, meaning "yield (expr, expr)" in any context where "yield expr" is valid Hmmm, it seems you're right. I was testing it using my patched yield-from version of Python, where it has apparently become a syntax error. I didn't mean to break it, sorry! -- Greg ___ 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] PEP 405 (proposed): Python 2.8 Release Schedule
On 10/11/11 05:18, Amaury Forgeot d'Arc wrote: Do we need to designate a release manager? I nominate John Cleese. Although he's undoubtedly a busy man, this shouldn't take up too much of his time. -- Greg ___ 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] [SPAM: 3.000] [issue11682] PEP 380 reference implementation for 3.3
Guido van Rossum wrote: I see this as inevitable. By the time the parser sees 'yield' it has made its choices; the 'from' keyword cannot modify that. So whenever "yield expr" must be parenthesized, "yield from expr" must too. This is patently untrue, because by version of the grammar allows 'f(yield from x)', while disallowing 'f(yield x)'. I made a conscious decision to do that, and I'm a bit alarmed at this decision being overridden at the last moment with no debate. At the same time, "yield expr, expr" works; Um, no, that's a syntax error in any context, as far as I can see. but does "yield from expr, expr" mean anything? In my current grammar, it's a syntax error on its own, but 'f(yield from x, y)' parses as 'f((yield from x), y)', which seems like a reasonable interpretation to me. What's not quite so reasonable is that if you have an expression such as f(x) + g(y) and you decide to turn f into a generator, the obvious way to rewrite it would be yield from f(x) + g(y) but that unfortunately parses as yield from (f(x) + g(y)) If I'd thought about this more at the time, I would probably have tried to make the argument to yield-from something further down in the expression hierarchy, such as a power. That might be tricky to achieve while keeping the existing behaviour of 'yield', though. -- Greg ___ 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] [SPAM: 3.000] [issue11682] PEP 380 reference implementation for 3.3
Nick Coghlan wrote: In reviewing Zbyszek's doc updates and comparing them against the Grammar, I discovered a gratuitous change in the implementation: it allows a bare (i.e. no parentheses) 'yield from' as an argument to a function. I'll add a new test to ensure "yield from x" requires parentheses whenever "yield x" requires them (and fix the Grammar file on the implementation branch accordingly). Wait a minute, there's nothing in the PEP as accepted that mentions any such restriction. My intention was that it should be as easy as possible to replace any function call 'f(x)' with 'yield from f(x)'. If parentheses are required, then instead of f(yield from g(x)) we would have to write f((yield from g(x))) I can't see how this is an improvement in readability or clarity. -- Greg ___ 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] Identifier API
Martin v. Löwis wrote: That wouldn't be instead, but in addition - you need the variable name, anyway. But the details of exactly how the name is constructed could be kept as an implementation detail. Not sure whether there is actually a gain in readability - people not familiar with this would assume that it's a function call of some kind, which it would not be. To me the benefit would be that the name you write as the argument would be *exactly* the identifier it represents. If you have to manually add a prefix, there's room for a bit of confusion, especially if the prefix itself ends with an underscore. E.g. if the identifier is "__init__" and the prefix is "PyID_", do you write "PyID__init__" (two underscores) or "PyID___init__" (three underscores?) And can you easily spot the difference in your editor? -- Greg ___ 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] Identifier API
Martin v. Löwis wrote: So I think it needs a prefix. If you don't like PyId_, let me know what the prefix should be instead. Instead of an explicit prefix, how about a macro, such as Py_ID(__string__)? -- Greg ___ 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] New stringbench benchmark results
Steven D'Aprano wrote: Given that strings are immutable, would it not be an obvious optimization for replace to return the source string unchanged if the old and new substrings are equal, Only if this situation occurs frequently enough to outweigh the overhead of comparing the target and replacement strings. This check could be performed very cheaply when both strings are interned, so it might be worth doing in that case. -- Greg ___ 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] check for PyUnicode_READY look backwards
Benjamin Peterson wrote: Why not just have it return 0 on error? This would be more consistent with API functions that return "false" values like NULL But that would make it confusingly different from all the other functions that return ints. The NULL convention is only used when the function returns a pointer. -- Greg ___ 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] Status of the built-in virtualenv functionality in 3.3
Lennart Regebro wrote: +1 for env or sandbox or something else with "box" in it. Eggbox? Eggcrate? Incubator? -- Greg ___ 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] range objects in 3.x
Fernando Perez wrote: Now, I *suspect* (but don't remember for sure) that the option to have it right-hand-open-ended was to match the mental model people have for range: In [5]: linspace(0, 10, 10, endpoint=False) Out[5]: array([ 0., 1., 2., 3., 4., 5., 6., 7., 8., 9.]) In [6]: range(0, 10) Out[6]: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] My guess would be it's so that you can concatenate two sequences created with linspace covering adjacent ranges and get the same result as a single linspace call covering the whole range. I do hope, though, that the chosen name is *not*: - 'interval' - 'interpolate' or similar Would 'subdivide' be acceptable? -- Greg ___ 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] range objects in 3.x
Ethan Furman wrote: Well, actually, I'd be using it with dates. ;) Seems to me that one size isn't going to fit all. Maybe we really want two functions: interpolate(start, end, count) Requires a type supporting addition and division, designed to work predictably and accurately with floats extrapolate(start, step, end) Works for any type supporting addition, not recommended for floats -- Greg ___ 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] range objects in 3.x
Ethan Furman wrote: If it's generic, why should it live in math? Generic? Maybe that's it: grange() It's also an English word, unfortunately one with a completely unrelated meaning. :-( -- Greg ___ 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] range objects in 3.x
Alexander Belopolsky wrote:
("Comb" (noun) brings up the right image, but is probably too
informal and may be confused with a short for "combination.")
And also with "comb filter" for those who are into
signal processing.
--
Greg
___
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] range objects in 3.x
Alexander Belopolsky wrote: I don't think we'll gain anything by copying numpy code because linspace(start, stop, num) is effectively just arange(0, num) * step + start I don't think the intention was to literally copy the code, but to investigate borrowing the algorithm, in case it was using some special technique to maximise numerical accuracy. But from this it seems like it's just using the naive algorithm that we've already decided is not the best. -- Greg ___ 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] range objects in 3.x
Guido van Rossum wrote: Or, maybe what I'm trying to say is, if the user has start/end/count but the API wants start/step/count, after computing step = (end-start) / count, the value of start + count*step might not quite equal to end; whereas if the user has start/step/count but the API wants start/end/count I think there's nothing wrong with computing end = start + step*count. +1, that makes sense to me. And I don't like "linspace" either. Something more self explanatory such as "subdivide" or "interpolate" might be better. -- Greg ___ 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] range objects in 3.x
Ethan Furman wrote: The only reason I'm aware of at the moment is to prevent loss of functionality from 2.x range to 3.x range. Since 2.x range(...) is equivalent to 3.x list(range(...)), I don't see any loss of functionality there. Comparing range objects directly in 3.x is like comparing xrange objects in 2.x, and there the comparison was arbitrary -- it did *not* compare them like their corresponding lists: Python 2.7 (r27:82500, Oct 15 2010, 21:14:33) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> a = xrange(5) >>> b = xrange(5) >>> a > b True -- Greg ___ 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] Windows 8 support
Jeff Hardy wrote: Another question is whether Python can take advantage of WinRT (the new UI framework). It should be possible, as the new APIs were designed to be used from dynamic languages, but I haven't decided if I'm crazy enough to try it. WinRT certainly sounds like the way to go in the future. I'm glad to hear that .NET isn't going to take over the world after all! -- Greg ___ 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] [Python-checkins] cpython (3.2): Fix PyUnicode_AsWideCharString() doc: size doesn't contain the null character
Victor Stinner wrote: "NUL" is an abbreviation used in tables when you don't have enough space to write the full name: "null character". It's also the official name of the character, for when you want to be unambiguous about what you mean (e.g. "null character" as opposed to "empty string" or "null pointer"). I expect it's 3 chars for consistency with all the other control character names. -- Greg ___ 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] PEP 393 Summer of Code Project
Terry Reedy wrote: While it has apparently been criticized as 'conservative' (which is well ought to be), it has been rather progressive in promoting changes such as 'ph' to 'f' (fisica, fone) and dropping silent 'p' in leading 'psi' (sicologia) and silent 's' in leading 'sci' (ciencia). I find it curious that pronunciation always seems to take precedence over spelling in campaigns like this. Nowadays, especially with the internet increasingly taking over from personal interaction, we probably see words written a lot more often than we hear them spoken. Why shouldn't we change the pronunciation to match the spelling rather than the other way around? -- Greg ___ 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] PEP 393 Summer of Code Project
Antoine Pitrou wrote: I don't think some American souvenir shop is a good reference, though :) (for example, there's no Paris street named "château de Versailles") Hmmm, I'd assumed they were reproductions of actual street signs found in Paris, but maybe not. :-( -- Greg ___ 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] PEP 393 Summer of Code Project
Terry Reedy wrote: Too bad, since people sometimes use '-' to serve the same purpose. Which actually seems more logical to me -- a separating symbol is better placed between the things being separated, rather than over the top of one of them! Maybe we could compromise by turning the diaeresis on its side: co:operate -- Greg ___ 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] PEP 393 Summer of Code Project
Guido van Rossum wrote: But in a word like "coëxistentie" (coexistence) the o and e do not form the oe-sound, and to emphasize this to Dutch readers (who believe their spelling is very logical :-), the official spelling puts the umlaut on the e. Sometimes this is done in English too -- occasionally you see words like "cooperation" spelled with a diaresis over the second "o". But these days it's more common to use a hyphen, or not bother at all. Everyone knows how it's pronounced. -- Greg ___ 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] PEP 393 Summer of Code Project
Guido van Rossum wrote: I recall long ago that when the french wrote words in all caps they would drop the accents, e.g. ECOLE. I even recall (through the mists of time) observing this in Paris on public signs. Is this still the convention? This page features a number of French street signs in all-caps, and some of them have accents: http://www.happymall.com/france/paris_street_signs.htm -- Greg ___ 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] Python 3 optimizations continued...
Nick Coghlan wrote: Personally, I *like* CPython fitting into the "simple-and-portable" niche in the Python interpreter space. Me, too! I like that I can read the CPython source and understand what it's doing most of the time. Please don't screw that up by attempting to perform heroic optimisations. -- Greg ___ 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] Ctypes and the stdlib (was Re: LZMA compression support in 3.3)
Guido van Rossum wrote: On Mon, Aug 29, 2011 at 2:17 PM, Greg Ewing wrote: All you need to do when writing the .pyx file is follow the same API that you would if you were writing C code to use the library. Interesting. Then how does Pyrex/Cython typecheck your code at compile time? You might be reading more into that statement than I meant. You have to supply Pyrex/Cython versions of the C declarations, either hand-written or generated by a tool. But you write them based on the advertised C API -- you don't have to manually expand macros, work out the low-level layout of structs, or anything like that (as you often have to do when using ctypes). -- Greg ___ 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] Ctypes and the stdlib (was Re: LZMA compression support in 3.3)
Guido van Rossum wrote: (Just like Python's own .h files -- e.g. the extensive renaming of the Unicode APIs depending on narrow/wide build) How does Cython deal with these? Pyrex/Cython deal with it by generating C code that includes the relevant headers, so the C compiler expands all the macros, interprets the struct declarations, etc. All you need to do when writing the .pyx file is follow the same API that you would if you were writing C code to use the library. -- Greg ___ 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] LZMA compression support in 3.3
Guido van Rossum wrote: On Sat, Aug 27, 2011 at 3:14 PM, Dan Stromberg wrote: IMO, we really, really need some common way of accessing C libraries that works for all major Python variants. We have one. It's called writing an extension module. I think Dan means some way of doing this without having to hand-craft a different one for each Python implementation. If we're really serious about the idea that "Python is not CPython", this seems like a reasonable thing to want. Currently the Python universe is very much centred around CPython, with the other implementations perpetually in catch-up mode. My suggestion on how to address this would be something akin to Pyrex or Cython. I gather that there has been some work recently on adding different back-ends to Cython to generate code for different Python implementations. -- Greg ___ 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] Should we move to replace re with regex?
Nick Coghlan wrote: The next step needed is for someone to volunteer to write and champion a PEP that: Would it be feasible and desirable to modify regex so that it *is* backwards-compatible with re, with a view to making it a drop-in replacement at some point? If not, the PEP should discuss this also. -- Greg ___ 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] PEP 393 Summer of Code Project
M.-A. Lemburg wrote: Simply going with UCS-4 does not solve the problem, since even with UCS-4 storage, you can still have surrogates in your Python Unicode string. Yes, but in that case, you presumably *intend* them to be treated as separate indexing units. If you didn't, there would be no need to use surrogates in the first place. -- Greg ___ 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] PEP 393 Summer of Code Project
Paul Moore wrote: IronPython and Jython can retain UTF-16 as their native form if that makes interop cleaner, but in doing so they need to ensure that basic operations like indexing and len work in terms of code points, not code units, if they are to conform. ... They lose the O(1) guarantee, but that's easily defensible as a tradeoff to conform to underlying runtime semantics. I would only agree as long as it wasn't too much worse than O(1). O(log n) might be all right, but O(n) would be unacceptable, I think. -- Greg ___ 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] PEP 393 Summer of Code Project
On 25/08/11 14:29, Guido van Rossum wrote: Let's get things right so users won't have to worry about code points vs. code units any more. What about things like the surrogateescape codec that deliberately use code units in non-standard ways? Will tricks like that still be possible if the code-unit level is hidden from the programmer? -- Greg ___ 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] GIL removal question
Sturla Molden wrote: With one interpreter per thread, and a malloc that does not let threads share memory pages (one heap per thread), Python could do the same. Wouldn't that be more or less equivalent to running each thread in a separate process? -- Greg ___ 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] cpython (2.7): note Ellipsis syntax
Benjamin Peterson wrote: why would you use Ellipsis outside of slices? I could imagine someone wanting to use it as part of a function API. For example, print(a, b, c, ...) would have been a nice way to tell print() not to put a newline on the end. -- Greg ___ 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] Import lock considered mysterious
I recently encountered a very mysterious bug in which
a background thread would inexplicably hang while attempting
to make a connection using httplib.
Debugging as far as I could at the Python level led to
the surprising conclusion that it was hanging while
using the ascii codec to encode the host name.
I couldn't imagine why, until I resorted to breaking into
it with gdb and found that it was trying to import
"codecs.ascii", and blocked on acquiring the import lock.
The reason for *that* was that my main module was a stub
that imported the real main module, which did all its
work directly from the module code. So the whole program
was effectively running inside an import statement and
holding onto the import lock.
Once I realised what was happening, it was easy to fix,
but I'm a bit disturbed about how difficult it was to
track down the cause.
This whole episode seems to have resulted from a collision
between two rather obscure things: that import statements
involve locking things, and that some fairly innocuous
looking calls, such as s.encode('ascii'), can trigger an
import.
I'm wondering whether anything can be done to make problems
like this less likely to occur, or at least to make the
cause more readily apparent. One shouldn't really have to
use gdb to track down bugs in Python code.
Is it really necessary to hold the import lock for so long?
Presumably the import lock is there to protect access to
things like sys.modules. Is that all? Could it be released
after the module code is loaded and sys.modules has been
updated, but before executing the module body?
--
Greg
___
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] Draft PEP: "Simplified Package Layout and Partitioning"
P.J. Eby wrote: "from x import y" means "import x; y = x.y". It actually means slightly more that that if y is a submodule, in which case it means "import x.y; y = x.y". -- Greg ___ 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] Draft PEP: "Simplified Package Layout and Partitioning"
Antoine Pitrou wrote: The additional confusion lies in the fact that a module can be shadowed by something which is not a module (a mere global variable). I find it rather baffling. I think we're stuck with that as long as we use the same syntax for importing a submodule and importing a non-module name from a module, i.e. 'from x import y'. -- Greg ___ 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] PEP 397 (Python launcher for Windows) reference implementation
Vinay Sajip wrote: the installation of a pre-3.3 version of Python after Python 3.3 is installed with the launcher will, if the user selects "Register Extensions", hijack the laumcher's associations to that earlier Python. Then bye bye launcher I don't see how anything can be done about that. It also doesn't seem like too serious a problem -- it's no worse than what currently happens if you install an older version over a newer one, i.e. associations revert to the old version. Making the launcher a separate install at least offers a way of fixing that if it happens and isn't desired, i.e. reinstall the launcher. -- Greg ___ 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] PEP 397 (Python launcher for Windows) reference implementation
Mark Hammond wrote: On 2/07/2011 7:08 PM, Vinay Sajip wrote: perhaps we could remember the last non-launcher association when we install the launcher, It might be better to look in the registry for other Python installations and ask the user which one to restore if there is more than one. Trying to restore the "last" one would be prone to breakage if the user didn't uninstall versions in precisely the reverse of the order of installation. -- Greg ___ 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] Patching builtin_id to allow for C proxy objects?
Tom Whittock wrote: Currently every time one of these objects is accessed from Python, a new "myproxy" instance is created. So if I were to access the same field of an object twice, I would receive two python objects proxying the same underlying C++ object. Perhaps you could use a WeakValueDictionary to keep a mapping from a C++ object address to its Python proxy. Then as long as a proxy object is alive, accessing the same C++ object again will get you the same proxy object. When there are no longer any references to the proxy object from Python, it will go away. The next time you access that C++ object you'll get a new proxy, but that won't matter, because the original proxy is no longer around to compare it with. This depends on there being some way for the proxy object to ensure that the C++ object remains alive as long as it does. It also won't solve the problem of keeping the id of the proxy for longer than the proxy exists, but that's probably not something you should be relying on anyway. The id of *any* Python object is only valid while the object lives, and if it's still alive you have a real reference somewhere that you can use instead of the id for identity testing. -- Greg ___ 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] ctypes: Configurable bitfield allocation strategy
Vlad Riscutia wrote: Longer term though, I think it would be better to add a property on the Structure class for configurable allocation strategy, for example Native (default), GCC, MSVC It could also be good to have a mode which lets you specify *exactly* how the bits are laid out, independent of any particular compiler. -- Greg ___ 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] EuroPython Language Summit report
P.J. Eby wrote: At 10:46 AM 6/25/2011 +1000, Nick Coghlan wrote: Indeed, PEP 380 is *really* hard to do properly without language support. No, it isn't. You add a decorator, a 'from_' class, and a 'return_' function, and there you go. (See my previous code sketches here in early PEP 380 discussions.) Will it handle *all* of the generator protocol correctly, including send(), exception handling, and generator closing? Also, how efficient would it be? A major benefit of a built-in implementation is that it can be almost as fast as using the sub-generator directly. -- Greg ___ 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] EuroPython Language Summit report
Nick Coghlan wrote: Indeed, PEP 380 is *really* hard to do properly without language support. The language moratorium and lack of a Python 3 compatible patch Pardon? My original patch was for 3.1.2. -- Greg ___ 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] PEP 3101 implementation vs. documentation
Ben Wolfson wrote: If by "item selector" you mean (using the names from the grammar in the docs) the element_index, I don't see why this should be the case; dictionaries can contain non-identified keys, after all. Of course they can, but that's not the point. The point is that putting arbitrary strings between [...] in a format spec without any form of quoting or requirement for bracket matching leads to something that's too confusing for humans to read. IMO the spec should be designed so that the format string can be parsed using the same lexical analysis rules as Python code. That means anything that is meant to "hang together" as a single unit, such as an item selector, needs to look like a single Python token, e.g. an integer or identifier. I realise this is probably more restrictive than the PEP suggests, but I think it would be better that way all round. -- Greg ___ 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] Lazy unpacking for struct module
Raymond Hettinger wrote: How would you describe the creation of a lazy result that keeps a reference to the underlying buffer? I'd call it a view. There is plenty of precedence for this kind of object in Python -- I gave a few examples before. The distinguishing feature of ropes, as I understand the term, is that you get a lazy object when you *combine* other objects, e.g. concatenating strings. That's not being asked for here -- there is only taking apart going on, not putting together. It's also different from the oft-rejected idea of lazy string slicing, because extracting a field would give you a separate object, e.g. an int or string, not a reference to the original data object being unpacked. So I really can't see what harm it could do, except for maybe a tiny performance reduction in the case where you extract all the fields, or refer to extracted fields repeatedly. Even if that turned out to be the case, and was considered objectionable, it could still be useful to provide view-oriented unpacking as an option. -- Greg ___ 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] Lazy unpacking for struct module
Raymond Hettinger wrote: The problem you're trying to solve isn't unique to structs. That's why we get periodic requests for ropes-like behaviors I don't think he's asking for rope-like behaviour here. Rather, he's asking for iterator-like or view-like behaviour -- for the same reasons we have both zip() and izip(), for example, or that dict.items() became a view in Py3. It seems like a reasonable request to me. However, I'm wondering whether the ctypes module might already provide what he wants. -- Greg ___ 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] Python 3.x and bytes
Guido van Rossum wrote:
On Thu, May 19, 2011 at 1:43 AM, Nick Coghlan wrote:
Proposals to address this include:
- introduce a "character" literal to allow c'a' as an alternative to
ord('a')
-1; the result is not a *character* but an integer.
Would you be happier if it were spelled i'a' instead?
--
Greg
___
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] PEP 3101 implementation vs. documentation
Ben Wolfson wrote:
You can't have an internal replacement
field in this part of the replacement field, so '{' can always safely
be assumed to be Just a Brace and not the start of a replacement
field, regardless of whether it's doubled,
I'm worried that the rules in this area are getting too
complicated for a human to follow. If braces are allowed
as plain data between square brackets and/or vice versa,
it's going to be a confusing mess to read, and there will
always be some doubt in the programmer's mind as to whether
they have to be escaped somehow or not.
I'm inclined to think that any such difficult cases should
simply be disallowed. If the docs say an identifier is required
someplace, the implementation should adhere strictly to that.
It's not *that* hard to parse an indentifier properly, and
IMO any use case that requires putting arbitrary characters
into an item selector is abusing the format mechanism and
should be redesigned to work some other way.
--
Greg
___
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] [Python-checkins] peps: Add rules for indenting continuation lines.
Guido van Rossum wrote: Bingo. That's why. (Though you are missing some colons in your examples. :-) --Guido On Thu, Jun 2, 2011 at 11:50 AM, Glenn Linderman wrote: One place a double indent is extremely nice is for lines that initiate a new indentation, but are themselves continued: if some_function( Some, Parameters, To, Pass, ) If_True_Operations() Another way to approach that is if some_function( Some, Parameters, To, Pass, ): If_True_Operations() i.e. indent the *body* one more place. This avoids the jarriness of seeing an outdent that doesn't correspond to the closing of a suite. -- Greg ___ 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] Don't set local variable in a list comprehension or generator
Victor Stinner wrote: I suppose that you have the current value of range(1) on the stack: DUP_TOP; BINARY_MULTIPLY; gives you the square. You don't need the x variable (LOAD_FAST/STORE_FAST). That seems far too special-purpose to be worth it to me. -- Greg ___ 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] Don't set local variable in a list comprehension or generator
Victor Stinner wrote: squares = (x*x for x in range(1)) What bytecode would you optimise that into? -- Greg ___ 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] Python 3.x and bytes
Ethan Furman wrote: some_var[3] == b'd' 1) a check to see if the bytes instance is length 1 2) a check to see if i) the other object is an int, and 2) 0 <= other_obj < 256 3) if 1 and 2, make the comparison instead of returning NotImplemented? It might seem convenient, but I'd worry that it would lead to even more confusion in other ways. If someone sees that some_var[3] == b'd' is true, and that some_var[3] == 100 is also true, they might expect to be able to do things like n = b'd' + 1 and get 101... or maybe b'e'... -- Greg ___ 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] Python 3.x and bytes
Eric Smith wrote: And of course it's too late to make any change to this. It's too late to change the meaning of b'...', but is it really too late to introduce an x'...' literal and change the repr() to produce it? -- Greg ___ 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] Python 3.x and bytes
Georg Brandl wrote:
We do have
bytes.fromhex('deadbeef')
But again, there is a run-time overhead to this.
--
Greg
___
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] Python 3.x and bytes
Robert Collins wrote: urlparse converting bytes to 'str' to operate on them is at best a kludge - you're forcing 5 times the storage (the original bytes + 4 bytes-per-byte when its decoded into unicode) That is itself an implementation detail of current Python, though, due to it only having one internal representation of unicode. In principle there could be a form of str that keeps its data encoded in latin1, in which case constructing it from a byte string could simply involve storing a pointer to the original bytes data. -- Greg ___ 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] Python 3.x and bytes
Ethan Furman wrote: On the one hand we have the 'bytes are ascii data' type interface, and on the other we have the 'bytes are a list of integers between 0 - 256' interface. I think the weird part is that there exists a literal for writing a byte array as an ascii string, and furthermore that it's the *only* kind of literal available for bytes. Personally I think that the default literal syntax for bytes, and also the form produced by repr(), should have been something more neutral, such as hex, with the ascii form available for use when it makes sense. Currently if you want to write a bytes literal in hex, you have to say something like some_var = b'\xde\xad\xbe\xef' which is ugly and unreadable. Much nicer would be some_var = x'deadbeef' As for --> some_other_var[3] == b'd' there ought to be a literal for specifying an integer using an ascii character, so you could say something like if some_other_var[3] == c'd': which would be equivalent to if some_other_var[3] == ord(b'd') but without the overhead of computing the value each time at run time. -- Greg ___ 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] Borrowed and Stolen References in API
Marvin Humphrey wrote: incremented: The caller has to account for an additional refcount. decremented: The caller has to account for a lost refcount. I'm not sure that really clarifies anything. These terms sound like they're talking about the reference count of the object, but if they correspond to borrowed/stolen, they don't necessarily correlate with what actually happens to the reference count. -- Greg ___ 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] Borrowed and Stolen References in API
Nick Coghlan wrote: One interesting aspect is that from the caller's point of view, a *new* reference to the relevant behaves like a borrowed reference for input parameters, but like a stolen reference for output parameters and return values. I think it's less confusing to use the term "new" only for output/return values, and "stolen" only for input values. Inputs are either "borrowed" or "stolen" (by the callee). Outputs are either "new" (to the caller) or "borrowed" (by the caller). (Or maybe the terms for outputs should be "given" and "lent"?-) -- Greg ___ 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
