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
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
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
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
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,
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
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
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
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
__
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
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
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
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
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
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
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
[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
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
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
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
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
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
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
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
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
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
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
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
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-
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
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
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
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
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
___
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
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,
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
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
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
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
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.
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
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
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
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
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
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
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
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()
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
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
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
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
___
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
_
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
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
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
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
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
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
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
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
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
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
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
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
_
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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(
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
1701 - 1800 of 2443 matches
Mail list logo