Re: [Python-Dev] Add python.exe to PATH environment variable

2008-09-03 Thread Greg Ewing
Eric Smith wrote: But I agree that managing a single batch file is easier than dealing with the PATH variable, and has fewer side effects (finding DLL's, etc.). This would only be possible for an administrator installation, though, not a per-user one. -- Greg

Re: [Python-Dev] Add python.exe to PATH environment variable

2008-09-03 Thread Greg Ewing
M.-A. Lemburg wrote: However, always having the latest version on PATH is not an option either, since e.g. I wouldn't want all .py scripts to be run by Python 3.0 just because I installed it for testing purposes. Keep in mind that the normal installation process on unix *does* make "python" re

Re: [Python-Dev] Add python.exe to PATH environment variable

2008-09-03 Thread Greg Ewing
Tim Golden wrote: You can use "CALL" within one batch file to chain another, returning afterwards to the first. You need to know that what you're calling is a bat file to have the foresight to do that, though. I can imagine people not expecting "python" to be a bat file. Instead of a bat file

Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

2008-09-05 Thread Greg Ewing
Kevin Teague wrote: There can be subtle differences between a "stock" Python and the system Python on Mac OS X 10.5. Also there can be different versions of Python installed in different versions of MacOSX. So if you distribute an app that relies on the system Python, at the least you have to

Re: [Python-Dev] Add python.exe to PATH environment variable

2008-09-08 Thread Greg Ewing
Martin v. Löwis wrote: OTOH, other things *are* available, such as registered extensions. For example, you don't need python on PATH to start a Python script; just invoking the .py file will find the Python interpreter from the registry. But then you don't get to pass arguments to the program,

Re: [Python-Dev] Filename as byte string in python 2.6 or 3.0?

2008-09-29 Thread Greg Ewing
Ulrich Eckhardt wrote: AFAIK, OS X guarantees UTF-8 for filesystem encodings. So the OS also provides Unicode filenames and how it deals with broken or legacy media is left up to the OS. Does this mean that the OS always returns valid utf-8 strings from filesystem calls, even if the media is

Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue

2008-09-30 Thread Greg Ewing
M.-A. Lemburg wrote: In the end, I think it's better not to be clever and just return the filenames that cannot be decoded as bytes objects in os.listdir(). But since it's a rare occurrence, most applications are just going to ignore the issue, and then fail unexpectedly one day on some unsuspe

Re: [Python-Dev] if-syntax for regular for-loops

2008-10-03 Thread Greg Ewing
Vitor Bosshard wrote: On Fri, Oct 3, 2008 at 6:10 AM, Andreas Nilsson wrote: Essentially, all that saves is a newline or two, which, as I think has been generally accepted, tends to hurt readability. The exact same argument could be used for list comprehensions themselves. No, an LC saves m

Re: [Python-Dev] if-syntax for regular for-loops

2008-10-05 Thread Greg Ewing
Nick Coghlan wrote: it was just odd to notice that the Py3k interpreter would quite happily execute the example code in my postscript when I had really only intended to write it as pseudo-code with sections missing. Well, they do say that Python is executable pseudocode. :-) -- Greg __

Re: [Python-Dev] __getattr__ and new style classes

2008-10-08 Thread Greg Ewing
Kristján Valur Jónsson wrote: Using new style classes to provide attribute-like access using __getattr__ is considerably slower than old style classes Do you really need __getattr__, or could you use properties instead? -- Greg ___ Python-Dev mailin

Re: [Python-Dev] __getattr__ and new style classes

2008-10-09 Thread Greg Ewing
Nick Coghlan wrote: If the time is being spent in PyErr_Format, how far could you get adding a dedicated function for creating AttributeErrors? Something along the lines of: PyErr_AttributeError(PyObject *object, PyObject *attr_name) More generally, it might be useful to have some mechanism f

Re: [Python-Dev] __getattr__ and new style classes

2008-10-09 Thread Greg Ewing
Amaury Forgeot d'Arc wrote: But this is already the case, and the reason why there are three variable to describe an exception: type, value and traceback. Yes, but you only get one object for the value, which means at least allocating a tuple if you want to be able to report something like "At

Re: [Python-Dev] [pygtk] Application name is '-c'

2008-10-14 Thread Greg Ewing
Frédéric wrote: In several places, instead of having my application name, I get '-c'. This could be a result of the app having got launched via 'python -c' somewhere along the way: % python -c 'import sys; print sys.argv[0]' -c Not sure whether to regard this as a bug or not. It's not clear w

Re: [Python-Dev] [ANN] VPython 0.1

2008-10-23 Thread Greg Ewing
Adam Olsen wrote: To clarify: This is *NOT* actually a form of threading, is it? I think the term "threaded code" is being used here in the sense of Forth, i.e. instead of a sequence of small integers that are dispatched using a switch statement, you use the actual machine addresses of the swi

Re: [Python-Dev] [ANN] VPython 0.1

2008-10-23 Thread Greg Ewing
Daniel Stutzbach wrote: With threaded code, every handler ends with its own dispatcher, so the processor can make fine-grained predictions. I'm still wondering whether all this stuff makes a noticeable difference in real-life Python code, which spends most of its time doing expensive things li

Re: [Python-Dev] [ANN] VPython 0.1

2008-10-23 Thread Greg Ewing
Guido van Rossum wrote: there already is something else called VPython Perhaps it could be called Fython (Python with a Forth-like VM) or Thython (threaded-code Python). -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.or

Re: [Python-Dev] [ANN] VPython 0.1

2008-10-23 Thread Greg Ewing
[EMAIL PROTECTED] wrote: Is there any reason this should be a separate project rather than just be rolled in to the core? Always keep in mind that one of the important characteristics of CPython is that its implementation is very straightforward and easy to follow. Replacing the ceval loop wit

Re: [Python-Dev] [ANN] VPython 0.1

2008-10-24 Thread Greg Ewing
Stefan Behnel wrote: Funny to hear that from the author of a well-known code generator. ;-) I've never claimed that anything about the implementation of Pyrex is easy to follow. :-) Having two switch statements and a couple of separate special cases for a single eval loop might look pretty a

Re: [Python-Dev] [ANN] VPython 0.1

2008-10-25 Thread Greg Ewing
A.M. Kuchling wrote: A stray thought: does using a generator for the VM make life easier for the Stackless Python developers in any way? Does it make it possible for stock CPython to become stackless? I doubt it. A major barrier to stacklessness is that a lot of extension modules would need t

Re: [Python-Dev] [ANN] VPython 0.1

2008-10-26 Thread Greg Ewing
Stefan Behnel wrote: That's obviously a problem, but it only answers the second question, not the first one. [does using a generator for the VM make life easier for the Stackless Python developers in any way?] The Stackless Python developers themselves would have to answer that one, but my gue

Re: [Python-Dev] Fwd: Removal of GIL through refcounting removal.

2008-11-02 Thread Greg Ewing
Eric Smith wrote: I'd gladly trade deterministic destruction (due to reference counting or any other mechanism) for improved performance. Another thing to consider is that refcounting spreads out the time spent doing GC evenly over the execution of the program, so that you don't get pauses occ

Re: [Python-Dev] Looking for VCS usage scenarios

2008-11-04 Thread Greg Ewing
Brett Cannon wrote: I have yet to have met anyone who thinks git is great while having used another DVCS as extensively (and I mean I have never found someone who has used two DVCSs extensively). It's entirely possible that there's only room for one VCS at a time in the average human brain. I

Re: [Python-Dev] Optionally using GMP to implement long if available

2008-11-04 Thread Greg Ewing
Martin v. Löwis wrote: On Windows, the GMP binaries would be incorporated into pythonxy.dll. This would force anybody providing a copy of pythonxy.dll to also provide the sources of GMP. I thought the suggestion was to provide a way of optionally compiling Python to use GMP. The standard Pytho

Re: [Python-Dev] Optionally using GMP to implement long if available

2008-11-04 Thread Greg Ewing
Martin v. Löwis wrote: you *will* have to ship gmp.dll to your users, as well ... So then > you have to include the source (of GMP Are you sure? I thought the source-provision requirements of the *GPL licences only apply when you distribute a *modified* version of something. Here you're just sh

Re: [Python-Dev] Using Cython for standard library?

2008-11-04 Thread Greg Ewing
C. Titus Brown wrote: Cython is a non-backwards-compatible fork of Pyrex, forked for the usual reasons [0]. As I see it, there are two main reasons for the fork: (1) I prefer to develop slowly and carefully, whereas the Cython people like to rush ahead and try out wild ideas. (2) There's a d

Re: [Python-Dev] Looking for VCS usage scenarios

2008-11-04 Thread Greg Ewing
Cosmin Stejerean wrote: Yes, Python is fast enough most of the time, but when it's not we put a lot of effort into making it faster. That's why we have a good collection of modules with C extensions to speed up computationally intensive applications So the Pythonic solution is, of course, t

Re: [Python-Dev] Optionally using GMP to implement long if available

2008-11-09 Thread Greg Ewing
Tim Peters wrote: because /knowing/ whether it works requires staring at generated code, there's probably no sane way to automate detection of when, if, and under what conditions it breaks. Maybe it could be tested by compiling two small test programs, one using (uint64_t)my_uint32 * my_other_u

Re: [Python-Dev] n.numbits: method or property?

2008-11-12 Thread Greg Ewing
Terry Reedy wrote: Math is pretty much float, not int functions. Also, it's supposed to be confining itself to wrapping the C math library. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev

Re: [Python-Dev] n.numbits: method or property?

2008-11-12 Thread Greg Ewing
Antoine Pitrou wrote: As for numbits, I think it should be a method It feels more method-like to me too, because it's something derived from the int's value rather than an independent piece of information. -- Greg ___ Python-Dev mailing list Python-

Re: [Python-Dev] n.numbits: method or property?

2008-11-12 Thread Greg Ewing
Aahz wrote: What do you call Decimal? ;-) If you're working with decimal numbers, you're more likely to want a numdigits() method. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscr

Re: [Python-Dev] Python for windows.

2008-11-27 Thread Greg Ewing
Bugbee, Larry wrote: As I recall, OpenSSL, a long while ago stopped, supporting some idiosyncrasies > associated with Windows I/O and opted for a "cleaner" approach, that of requiring developers to link a small file, applink.c, into the app's main. Could it not be linked into the openssl ext

Re: [Python-Dev] Python for windows.

2008-11-27 Thread Greg Ewing
Mark Hammond wrote: The only conflict I see here is the requirement to install into "\Program Files" Doesn't that just mean that if an OEM decides to preinstall it, they need to put it in Program Files? They're at liberty to do that. -- Greg ___ Pyt

Re: [Python-Dev] __import__ problems

2008-11-28 Thread Greg Ewing
Mart Somermaa wrote: But it is not. The proposed __import__(name, submodule=True) has a compatible interface. Actually, it's not. Keep in mind that __import__ isn't a particular function, it's a defined interface to a family of functions. If that interface is extended, any replacement __import

Re: [Python-Dev] Python-3.0, unicode, and os.environ

2008-12-07 Thread Greg Ewing
Nick Coghlan wrote: For binary wrappers around the Windows Unicode APIs, I was thinking specifically of using UTF-8, since that should be able to encode anything the Unicode APIs can handle. Why shouldn't the binary interface just expose the raw utf16 as bytes? -- Greg ___

Re: [Python-Dev] Allocation of shape and strides fields in Py_buffer

2008-12-08 Thread Greg Ewing
Antoine Pitrou wrote: (of course complex schemes can be devised where the callee maintains its own separate storage for shape and strides, but I don't think we want to go there) But that's exactly where you're supposed to be going. If the object providing the buffer has variable-sized shape an

Re: [Python-Dev] Allocation of shape and strides fields in Py_buffer

2008-12-09 Thread Greg Ewing
Nick Coghlan wrote: Maintaining a PyDict instance to map from view pointers to shapes and strides info doesn't strike me as a "complex scheme" though. I don't see why a given buffer provider should ever need more than one set of shape/strides arrays at a time. It can allocate them on creation,

Re: [Python-Dev] Allocation of shape and strides fields in Py_buffer

2008-12-09 Thread Greg Ewing
Antoine Pitrou wrote: That doesn't work if e.g. you take a slice of a memoryview object, since the shape changes in the process. See http://bugs.python.org/issue4580 I haven't looked in detail at how memoryview is currently implemented, but it seems to me that the way it should work is that wh

Re: [Python-Dev] Allocation of shape and strides fields in Py_buffer

2008-12-09 Thread Greg Ewing
Nick Coghlan wrote: [from the PEP] "If the exporter wants to be able to change an object's shape, strides, and/or suboffsets before releasebuffer is called then it should allocate those arrays when getbuffer is called (pointing to them in the buffer-info structure provided) and free them when re

Re: [Python-Dev] Allocation of shape and strides fields in Py_buffer

2008-12-09 Thread Greg Ewing
Antoine Pitrou wrote: Why should it need two? Why couldn't the embedded Py_buffer fullfill all the needs of the memoryview object? Two things here: 1) The memoryview should *not* be holding onto a Py_buffer in between calls to its getitem and setitem methods. It should request on

Re: [Python-Dev] Forking and pipes

2008-12-09 Thread Greg Ewing
Lars Kotthoff wrote: This prints out "foo" twice although it's only written once to the pipe. It seems that python doesn't flush file descriptors before copying them to the child process, thus resulting in the duplicate message. The equivalent C program behaves as expected, Your Python and C p

Re: [Python-Dev] Allocation of shape and strides fields in Py_buffer

2008-12-10 Thread Greg Ewing
Antoine Pitrou wrote: If the memoryview wasn't holding onto a Py_buffer, one couldn't rely on its length or anything else because the underlying object could be mutated at any moment Hmm, it seems there are two different approaches that could be taken here to the design of a memoryview object.

Re: [Python-Dev] Allocation of shape and strides fields in Py_buffer

2008-12-10 Thread Greg Ewing
Travis Oliphant wrote: When a slice view is made, a new memoryview object is created with a Py_buffer structure that needs to allocate it's own shape and strides (or something that will allow correct shape and strides to be reported to any consumer). In this way, there are two Py_buffer stru

Re: [Python-Dev] Allocation of shape and strides fields in Py_buffer

2008-12-10 Thread Greg Ewing
Nick Coghlan wrote: The multi-dimensional cases get pretty tricky though, since they will almost always end up dealing with non-contiguous data. The PEP 3118 protocol is up to handling the task, but the implementation of the index mapping to handle these multi-dimensional cases is highly non-tri

Re: [Python-Dev] Allocation of shape and strides fields in Py_buffer

2008-12-10 Thread Greg Ewing
Antoine Pitrou wrote: - it uses something (Py_buffer) which is not a PyObject and has totally different allocation/lifetime semantics This was a deliberate decision -- in fact I argued for it myself. The buffer interface is meant to be a minimal-overhead way for C code to get at the underlying

Re: [Python-Dev] Calling the GC less often when there are lots of long-lived objects

2008-12-16 Thread Greg Ewing
Antoine Pitrou wrote: I've proposed a patch which basically implements Martin's suggestion in http://mail.python.org/pipermail/python-dev/2008-June/080579.html Is anybody opposed to the principle of this proposal? Sounds okay to me. -- Greg ___ Pyth

Re: [Python-Dev] The endless GIL debate: why not remove thread support instead?

2008-12-17 Thread Greg Ewing
Nick Coghlan wrote: Actually, I believe 3.0 already took a big step towards allowing this by changing the way modules are initialised. It's a step, but I wouldn't call it a big one. There are many other problems to be solved before fully independent interpreters are possible. -- Greg

Re: [Python-Dev] The endless GIL debate: why not remove thread support instead?

2008-12-18 Thread Greg Ewing
Paul Moore wrote: Do you know if these remaining problems are listed anywhere? There was a big discussion about this in comp.lang.python not long ago. Basically all the built-in types and constants are shared between interpreters, which means you still need a GIL to stop different interpreters

Re: [Python-Dev] Should there be a source-code checksum in module objects?

2009-02-02 Thread Greg Ewing
ro...@gnu.org wrote: But the expectation is that the programmer thinks it matches what is currently on A that the programmer is debuggging. Can I tell for certain? You can always find out by compiling the source and comparing the resulting bytecode with what is currently on A. Not that this is

Re: [Python-Dev] Missing operator.call

2009-02-05 Thread Greg Ewing
Hrvoje Niksic wrote: Is there a reason why the operator module doesn't have an operator.call function? I've been thinking about proposing an enhancement concerning generators that would entail making "call" a reserved word, so I'd be a little disappointed if this name were used. Maybe apply()

Re: [Python-Dev] Missing operator.call

2009-02-05 Thread Greg Ewing
Guido van Rossum wrote: What's so special about your proposal that requires a new keyword? I was thinking about the proposals that are made from time to time for things like yield *foo to yield all the items from a sub-generator. I was also thinking about what could be done to make using g

Re: [Python-Dev] Missing operator.call

2009-02-06 Thread Greg Ewing
Guido van Rossum wrote: Why is "call expr" a more enticing syntax than "yield *expr" ? I was thinking it would read better when you're using generators as lightweight threads, and you want the one-level-deep nature of generators to be hidden as much as possible. The fact that yielding is goin

Re: [Python-Dev] Missing operator.call

2009-02-06 Thread Greg Ewing
Stephen J. Turnbull wrote: Greg Ewing writes: > The fact that yielding is going on is not of > interest in that situation But doesn't "yield" in the sense of "yield the right of way" mean exactly that? I've no problem with using 'yield' when a

Re: [Python-Dev] cpython (2.7): note Ellipsis syntax

2011-07-30 Thread Greg Ewing
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 ___

Re: [Python-Dev] GIL removal question

2011-08-12 Thread Greg Ewing
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 _

Re: [Python-Dev] PEP 393 Summer of Code Project

2011-08-25 Thread Greg Ewing
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-u

Re: [Python-Dev] PEP 393 Summer of Code Project

2011-08-26 Thread Greg Ewing
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, bu

Re: [Python-Dev] PEP 393 Summer of Code Project

2011-08-26 Thread Greg Ewing
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 nee

Re: [Python-Dev] Should we move to replace re with regex?

2011-08-27 Thread Greg Ewing
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

Re: [Python-Dev] LZMA compression support in 3.3

2011-08-28 Thread Greg Ewing
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 withou

Re: [Python-Dev] Ctypes and the stdlib (was Re: LZMA compression support in 3.3)

2011-08-29 Thread Greg Ewing
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 macro

Re: [Python-Dev] Ctypes and the stdlib (was Re: LZMA compression support in 3.3)

2011-08-29 Thread Greg Ewing
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

Re: [Python-Dev] Python 3 optimizations continued...

2011-08-29 Thread Greg Ewing
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 optimisa

Re: [Python-Dev] PEP 393 Summer of Code Project

2011-09-01 Thread Greg Ewing
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

Re: [Python-Dev] PEP 393 Summer of Code Project

2011-09-01 Thread Greg Ewing
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 -- occasion

Re: [Python-Dev] PEP 393 Summer of Code Project

2011-09-01 Thread Greg Ewing
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

Re: [Python-Dev] PEP 393 Summer of Code Project

2011-09-01 Thread Greg Ewing
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 _

Re: [Python-Dev] PEP 393 Summer of Code Project

2011-09-02 Thread Greg Ewing
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 f

Re: [Python-Dev] [Python-checkins] cpython (3.2): Fix PyUnicode_AsWideCharString() doc: size doesn't contain the null character

2011-09-06 Thread Greg Ewing
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

Re: [Python-Dev] Windows 8 support

2011-09-14 Thread Greg Ewing
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 th

Re: [Python-Dev] range objects in 3.x

2011-09-23 Thread Greg Ewing
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 xr

Re: [Python-Dev] range objects in 3.x

2011-09-26 Thread Greg Ewing
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 sta

Re: [Python-Dev] range objects in 3.x

2011-09-27 Thread Greg Ewing
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

Re: [Python-Dev] range objects in 3.x

2011-09-27 Thread Greg Ewing
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 mai

Re: [Python-Dev] range objects in 3.x

2011-09-27 Thread Greg Ewing
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

Re: [Python-Dev] range objects in 3.x

2011-09-28 Thread Greg Ewing
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 accurat

Re: [Python-Dev] range objects in 3.x

2011-09-28 Thread Greg Ewing
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]: rang

Re: [Python-Dev] Status of the built-in virtualenv functionality in 3.3

2011-10-06 Thread Greg Ewing
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.pytho

Re: [Python-Dev] check for PyUnicode_READY look backwards

2011-10-06 Thread Greg Ewing
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

Re: [Python-Dev] New stringbench benchmark results

2011-10-06 Thread Greg Ewing
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 repl

Re: [Python-Dev] Identifier API

2011-10-13 Thread Greg Ewing
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@p

Re: [Python-Dev] Identifier API

2011-10-14 Thread Greg Ewing
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 wou

Re: [Python-Dev] [SPAM: 3.000] [issue11682] PEP 380 reference implementation for 3.3

2011-11-09 Thread Greg Ewing
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 parenthe

Re: [Python-Dev] [SPAM: 3.000] [issue11682] PEP 380 reference implementation for 3.3

2011-11-09 Thread Greg Ewing
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(

Re: [Python-Dev] PEP 405 (proposed): Python 2.8 Release Schedule

2011-11-09 Thread Greg Ewing
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@pytho

Re: [Python-Dev] [SPAM: 3.000] [issue11682] PEP 380 reference implementation for 3.3

2011-11-09 Thread Greg Ewing
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

Re: [Python-Dev] [SPAM: 3.000] [issue11682] PEP 380 reference implementation for 3.3

2011-11-09 Thread Greg Ewing
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 synta

Re: [Python-Dev] [SPAM: 3.000] [issue11682] PEP 380 reference implementation for 3.3

2011-11-09 Thread Greg Ewing
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

Re: [Python-Dev] A new dict for Xmas?

2011-12-15 Thread Greg Ewing
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 elimina

Re: [Python-Dev] Potential NULL pointer dereference in descrobject.c

2011-12-17 Thread Greg Ewing
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-arch

Re: [Python-Dev] Coroutines and PEP 380

2012-01-21 Thread Greg Ewing
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 whethe

Re: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review

2012-02-15 Thread Greg Ewing
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 milli

Re: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review

2012-02-18 Thread Greg Ewing
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

Re: [Python-Dev] State of PEP-3118 (memoryview part)

2012-02-26 Thread Greg Ewing
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 com

Re: [Python-Dev] PEP 414

2012-02-26 Thread Greg Ewing
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 s

Re: [Python-Dev] slice subscripts for sequences and mappings

2012-03-04 Thread Greg Ewing
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

Re: [Python-Dev] Sandboxing Python

2012-03-04 Thread Greg Ewing
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/listinf

Re: [Python-Dev] Sandboxing Python

2012-03-04 Thread Greg Ewing
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

Re: [Python-Dev] Sandboxing Python

2012-03-05 Thread Greg Ewing
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

Re: [Python-Dev] PEP czar for PEP 3144?

2012-03-20 Thread Greg Ewing
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 c

Re: [Python-Dev] Python install layout and the PATH on win32

2012-03-20 Thread Greg Ewing
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 place

<    13   14   15   16   17   18   19   20   21   22   >