On Jan 27, 2005, at 1:20 AM, Martin v. Löwis wrote:
I agree. Because of the BDFL pronouncement, I cannot reject the patch,
but I won't accept it, either. So it seems that this patch will have
to sit in the SF tracker until either Guido processes it, or it is
withdrawn.
If people want to restart thi
On Feb 14, 2005, at 10:41 AM, Tim Peters wrote:
Wouldn't it be more elegant to make builtin_id() return an unsigned
long integer?
I think so. This is the function ZODB 3.3 uses, BTW:
def positive_id(obj):
"""Return id(obj) as a non-negative integer."""
[...]
I think it'd be nice to change it,
On Mar 9, 2005, at 4:19 PM, Thomas Heller wrote:
If this were the only use case, you are right. I cannot remember the
use case I once had right now, and probably the code has been rewritten
anyway. But I assume use cases exist, otherwise there weren't so many
recipes for the ordered dictionary.
I
On Mar 11, 2005, at 2:02 PM, Steven Bethard wrote:
On Fri, 11 Mar 2005 19:48:45 +0100, Alex Martelli <[EMAIL PROTECTED]>
wrote:
Which reminds me -- could we have a methodcaller relative to
attrgetter
and itemgetter? "Sort a list of strings in a case-insensitive way"
would become *SO* easy with s
On Mar 18, 2005, at 8:19 PM, Greg Ward wrote:
Is having to use fcntl and os really so awful? At least it requires
the programmer to prove he knows what he's doing putting this file
into non-blocking mode, and that he really wants to do it. ;-)
I'd tend to agree. :) Moreover, I don't think fread/f
On Apr 9, 2005, at 2:13 PM, Michael Hudson wrote:
The funniest I know is part of PyPy:
def extract_cell_content(c):
"""Get the value contained in a CPython 'cell', as read through
the func_closure of a function object."""
# yuk! this is all I could come up with that works in Python 2.2
On Apr 9, 2005, at 5:37 PM, Ka-Ping Yee wrote:
Let me know if you figure out how to defeat that.
You can protect against this, too, but it does show that it's *really*
hard to get restricting code right...I'm of the opinion that it's not
really worth it -- you should just use OS protections.
unt
On Apr 10, 2005, at 11:22 AM, Michael Hudson wrote:
Bob Ippolito <[EMAIL PROTECTED]> writes:
Is there a good reason to *not* call PyEval_InitThreads when using a
threaded Python?
Well, it depends how expensive ones OS's locking primitives are, I
think. There were some numbers posted to the twisted
On Apr 20, 2005, at 5:43 AM, Paul Moore wrote:
and the substitution of
@EXPR:
CODE
would become something like
def __block():
CODE
EXPR(__block)
The question of whether assignments within CODE are executed within a
new namespace, as this implies, or in the surrounding namespace,
remains open.
On May 3, 2005, at 12:53 PM, Guido van Rossum wrote:
> def saving_stdout(f):
> save_stdout = sys.stdout
> try:
> sys.stdout = f
> yield
> finally:
> sys.stdout = save_stdout
I hope you aren't going to be using that in any threaded program.
That's one really nic
On May 6, 2005, at 2:49 PM, Nicholas Bastin wrote:
> If this is the case, then we're clearly misleading users. If the
> configure script says UCS-2, then as a user I would assume that
> surrogate pairs would *not* be encoded, because I chose UCS-2, and it
> doesn't support that. I would assume th
On May 10, 2005, at 2:48 PM, Nicholas Bastin wrote:
> On May 9, 2005, at 12:59 AM, Martin v. Löwis wrote:
>
>
>>> Wow, what an inane way of looking at it. I don't know what world
>>> you
>>> live in, but in my world, users read the configure options and
>>> suppose
>>> that they mean somethin
On May 12, 2005, at 6:32 PM, Ka-Ping Yee wrote:
> Suppose exceptions have an optional "context" attribute, which is
> set when the exception is raised in the context of handling another
> exception. Thus:
>
> def a():
> try:
> raise AError
> except:
> r
On May 14, 2005, at 2:34 PM, Aahz wrote:
> On Fri, May 13, 2005, Greg Ewing wrote:
>
> Sounds reasonable, but it should be equally easy to handle::
>
> raise MyError, "message"
Make that:
raise MyError("message")
There's really no reason for a multi-argument raise when exceptions
are ob
On May 19, 2005, at 8:43 AM, Phillip J. Eby wrote:
> At 06:09 PM 5/19/2005 +1200, Greg Ewing wrote:
>> Guido van Rossum wrote:
>>> - When a generator is GC'ed, its close() method is called (which
>>> is a
>>> no-op if it is already closed).
>>
>> Does this mean that all generators will be ineligi
On May 20, 2005, at 4:31 AM, Ka-Ping Yee wrote:
> Guido van Rossum wrote:
>
>> Do we really need both __context__ and __cause__?
>>
>
> Well, it depends whose needs we're trying to meet.
>
> If we want to satisfy those who have been asking for chaining
> of unexpected secondary exceptions, then w
On May 20, 2005, at 6:37 PM, Phillip J. Eby wrote:
> This only helps if you can get to a debugger. What if you're
> reading your web server's error log?
Then you're in trouble anyways because you need the contents of some
local to figure out what's going on, also.
James
_
On Jun 12, 2005, at 10:20 PM, Raymond Hettinger wrote:
> I think it unwise to allow x to be any expression. Besides altering
> existing semantics, it leads to code redundancy and to a fragile
> construct (where the slightest alteration of any of the expressions
> triggers a silent reversion to O(n
On Jun 16, 2005, at 10:50 AM, Steven Bethard wrote:
> On 6/15/05, Benji York <[EMAIL PROTECTED]> wrote:
>
>> Steven Bethard wrote:
>>
>>> I would prefer that the alternate iter() form was broken off into
>>> another separate function, say, iterfunc(), that would let me write
>>> Jp's solution som
On Feb 13, 2006, at 7:09 PM, Guido van Rossum wrote:
> On 2/13/06, Michael Foord <[EMAIL PROTECTED]> wrote:
>> Sorry - I meant for the unicode to bytes case. A default encoding
>> that
>> behaves differently to the current to implicit encodes/decodes
>> would be
>> confusing IMHO.
>
> And I am
On Feb 14, 2006, at 12:20 AM, Phillip J. Eby wrote:
> bytes(map(ord, str_or_unicode))
>
> In other words, without an encoding, bytes() should simply treat
> str and
> unicode objects *as if they were a sequence of integers*, and
> produce an
> error when an integer is out of range. This i
On Feb 14, 2006, at 1:52 AM, Martin v. Löwis wrote:
> Phillip J. Eby wrote:
>> I was just pointing out that since byte strings are bytes by
>> definition,
>> then simply putting those bytes in a bytes() object doesn't alter the
>> existing encoding. So, using latin-1 when converting a string t
tring".
I'd like to point out that the previous proposal had the same issue:
On Feb 13, 2006, at 8:11 PM, Guido van Rossum wrote:
> On 2/13/06, James Y Knight <[EMAIL PROTECTED]> wrote:
>> In py3k, when the str object is eliminated, then what do you have?
>> Perhaps
On Feb 14, 2006, at 11:25 AM, Phillip J. Eby wrote:
> At 11:08 AM 2/14/2006 -0500, James Y Knight wrote:
>> I like it, it makes sense. Unicode strings are simply not allowed as
>> arguments to the byte constructor. Thinking about it, why would it be
>> otherwise? And if you&
On Feb 15, 2006, at 7:19 AM, Fuzzyman wrote:
> [snip..]
>
> I personally like the move towards all unicode strings, basically
> any text where you don't know the encoding used is 'random binary
> data'. This works fine, so long as you are in control of the text
> source. *However*, it leaves
On Feb 18, 2006, at 2:33 AM, Martin v. Löwis wrote:
> I don't understand. In the rationale of PEP 333, it says
> "The rationale for requiring a dictionary is to maximize portability
> between servers. The alternative would be to define some subset of a
> dictionary's methods as being the standard a
On Feb 22, 2006, at 6:35 AM, Greg Ewing wrote:
> I'm thinking of convenience, too. Keep in mind that in Py3k,
> 'unicode' will be called 'str' (or something equally neutral
> like 'text') and you will rarely have to deal explicitly with
> unicode codings, this being done mostly for you by the I/O
On Feb 24, 2006, at 1:54 AM, Greg Ewing wrote:
> Thomas Wouters wrote:
>> On Thu, Feb 23, 2006 at 05:25:30PM +1300, Greg Ewing wrote:
>>
>>> As an aside, is there any chance that this could be
>>> changed in 3.0? I.e. have the for-loop create a new
>>> binding for the loop variable on each iteratio
On Feb 28, 2006, at 6:14 PM, Guido van Rossum wrote:
> On 2/28/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Fredrik Lundh wrote:
>>
My personal goal in life right now is to stay as
far away from C++ as I can get.
>>>
>>> so what C compiler are you using ?
>>
>> Gcc, mostly. I don't mind
On Mar 29, 2006, at 1:38 PM, Martin v. Löwis wrote:
> Given that Barry insists so firmly that there is a need, and that
> this need arises from a significant code simplification that can
> be achieved through the API, the natural conclusion is to add
> the API. That, of course, assumes that you bel
On Apr 3, 2006, at 3:12 PM, Neil Schemenauer wrote:
> Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> This would require a bit "__del__ already called" on an object,
>> but don't we have a whole word of GC-related flags?
>
> No.
Actually there is. Kinda. Currently python's refcounting scheme uses
On Apr 3, 2006, at 4:02 PM, Tim Peters wrote:
> Using which compiler? This varies across boxes. Most obviously, on a
> 64-bit box all these members are 8 bytes (note that ob_refcnt is
> Py_ssize_t in 2.5, not int anymore), but even on some 32-bit boxes the
> "long double" trick only forces 4-byte
On Apr 4, 2006, at 11:41 PM, Alex Martelli wrote:
> IMHO, the solution to THAT very real problem is to supply a built-in
> function that catches some exceptions and maps them into suitable
> return values. Simplest would be something like:
[...]
> though I'm sure we can get better syntax if we turn
On Apr 19, 2006, at 3:19 PM, Phillip J. Eby wrote:
> At 08:45 PM 4/19/2006 +0200, M.-A. Lemburg wrote:
>> Phillip J. Eby wrote:
>>> At 09:02 PM 4/18/2006 +0200, M.-A. Lemburg wrote:
Phillip J. Eby wrote:
> At 07:15 PM 4/18/2006 +0200, M.-A. Lemburg wrote:
>> Why should a 3rd party ex
On Apr 26, 2006, at 4:49 PM, Guido van Rossum wrote:
> OK, forget it. I'll face the pitchforks.
>
> I'm disappointed though -- it sounds like we can never change anything
> about Python any more because it will upset the oldtimers.
>
No, you can not make a change which has a tiny (and arguably
n
On May 1, 2006, at 8:15 AM, Nick Coghlan wrote:
> 1. PEP 343, 2.5 alpha 1, 2.5 alpha 2 and the discussions here have
> no doubt
> seriously confused the meaning of the term 'context manager' for a
> lot of
> people (you can certainly put me down as one such person). Anyone
> not already
> c
On Jun 22, 2006, at 3:24 PM, Phillip J. Eby wrote:
> Well, you can't "def" a dotted name, but I realize this isn't a
> binding.
I have actually wanted to do that before. It would be nice if you
could. :)
James
___
Python-Dev mailing list
Python-De
On Jun 24, 2006, at 1:29 PM, Ralf W. Grosse-Kunstleve wrote:
> --- Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
>> I think it is safe to say that Twisted is more widely used than
>> anything
>> Google has yet released. Twisted also has a reasonably plausible
>> technical reason to dislike th
On Jun 25, 2006, at 9:47 PM, James Y Knight wrote:
>
> On Jun 24, 2006, at 1:29 PM, Ralf W. Grosse-Kunstleve wrote:
>
>> --- Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
>>> I think it is safe to say that Twisted is more widely used than
>>> anything
>
On Jun 30, 2006, at 3:05 AM, Neal Norwitz wrote:
> If there are any bugs you think should be considered show stoppers,
> mail them to the list and I will update the PEP.
I just submitted http://python.org/sf/1515169 for the ImportWarning
issue previously discussed here. IMO it's important.
Jame
On Jul 8, 2005, at 4:46 PM, Brett Cannon wrote:
> I think having basic context managers in a stdlib module that we know
> for a fact that will be handy is a good idea. We should keep the list
> short and poignant, but we should have something for people to work
> off of. The ones I like below for
On Jul 28, 2005, at 4:20 PM, Guido van Rossum wrote:
> Managing users is especially important -- if a
> user is compromised (as has happened in the past for python.org users)
> the whole repository is compromised. Now this could happen to SF users
> too, but I'm not sure that we know all the trick
On Jul 29, 2005, at 11:07 PM, Robert Brewer wrote:
> I'd recommend not subclassing SystemExit--there are too many programs
> out there which expect the argument (e.g. sys.exit(3)) to mean
> something
> specific, but that expectation doesn't apply at all to SystemError.
Yes please make note of t
On Jul 30, 2005, at 8:57 PM, Nick Coghlan wrote:
> I wouldn't mind using Exception/Error instead of Raisable/Exception
> - and it
> seriously reduces the pain of making this transition. Indeed, most
> of it
> becomes doable within the 2.x series - the only tricky parts are
> semantic
> change
On Aug 2, 2005, at 12:31 AM, Phillip J. Eby wrote:
> If you think that a KeyboardInterrupt is an error, then it's an
> indication
> that Python's documentation and the current exception class
> hierarchy has
> failed to educate you sufficiently, and that we *really* need to add a
> class like C
On Jul 31, 2005, at 12:49 PM, Phillip J. Eby wrote:
> I think you're ignoring the part where most exception handlers are
> already broken. At least adding CriticalException and
> ControlFlowException makes it possible to add this:
>
> try:
> ...
> except (CriticalException,Con
On Aug 3, 2005, at 3:00 PM, Guido van Rossum wrote:
> [...brain hums...]
>
> OK, I'm changing my mind again about the names again.
>
> Exception as the root and StandardError can stay; the only new
> proposal would then be to make bare 'except:' call StandardError.
I don't see how that can work. A
On Aug 4, 2005, at 7:03 AM, Nick Coghlan wrote:
> Additionally, consider that a hypothetical ThreadExit exception
> (used to
> terminate a thread semi-gracefully) would also clearly belong under
> ControlFlowException. That is, just because something is
> asynchronous with
> respect to the curr
>+-- NamespaceError (rename of NameError)
>+-- UnboundFreeError (new)
>+-- UnboundGlobalError (new)
>+-- UnboundLocalError
>
What are these new exceptions for? Under what circumstances are they
raised? Why is this necessary or an improvement?
> Rename
On Aug 5, 2005, at 2:46 PM, Raymond Hettinger wrote:
> The PEP moves StopIteration out from under Exception so that it cannot
> be caught by a bare except or an explicit "except Exception".
>
> IMO, this is a mistake. In either form, a programmer is stating that
> they want to catch and handle j
On Aug 8, 2005, at 12:14 PM, Guido van Rossum wrote:
> Ouch. Too much discussion to respond to it all. Please remember that
> in Jythin and IronPython, str and unicode are already synonyms. That's
> how Python 3.0 will do it, except unicode will disappear as being
> redundant. I like the bytes/froz
On Aug 9, 2005, at 7:15 PM, Raymond Hettinger wrote:
> The data gathered by Jack and Steven's research indicate that the
> number
> of cases where TerminatingException would be useful is ZERO. Try
> not to
> introduce a new builtin that no one will ever use. Try not to add
> a new
> word wh
On Aug 10, 2005, at 7:45 PM, Raymond Hettinger wrote:
>>> Then I don't follow what you mean by "moved under os".
>>>
>>
>> In other words, to get the exception, do ``from os import
>> WindowsError``. Unfortunately we don't have a generic win module to
>> put it under. Maybe in the platform modu
On Aug 11, 2005, at 2:41 PM, Josiah Carlson wrote:
> Remember, the Exception reorganization is for Python 3.0/3k/whatever,
> not for 2.5 .
Huh, I could *swear* we were talking about fixing things for
2.5...but I see at least the current version of the PEP says it's
talking about 3.0. If that's
On Aug 15, 2005, at 5:04 PM, Bryan O'Sullivan wrote:
> The centralised SCM tools all create a wall between core developers
> (i.e. people with commit access to the central repository) and people
> who are on the fringes. Outsiders may be able to get anonymous
> read-only access, but they are left
On Aug 16, 2005, at 2:52 AM, Martin v. Löwis wrote:
> Tim Peters wrote:
>
>> It would be best if svn:eol-style were set to native during initial
>> conversion from CVS, on all files not marked binary in CVS.
>>
>
> Ok, I'll add that to the PEP. Not sure how to implement it, yet...
cvs2svn does tha
On Aug 17, 2005, at 2:55 PM, Timothy Fitz wrote:
> On 8/16/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
>> -0 The behavior of dir() already a bit magical. Python is much
>> simpler
>> to comprehend if we have direct relationships like dir() and vars()
>> corresponding as closely as poss
On Aug 22, 2005, at 11:32 AM, Barry Warsaw wrote:
> They are the same machine, with different IP addresses. Anonymous
> webdav will require two Apache processes, since different user/groups
> are needed and to support different certs for svn.python.org and
> (eventually) www.python.org.
>
It see
On Aug 23, 2005, at 10:41 PM, Raymond Hettinger wrote:
> [Guido van Rossum]
>
>> If we syntactically enforce that the bare except, if present, must be
>> last, would that remove your objection? I agree that a bare except in
>> the middle is an anomaly, but that doesn't mean we can't keep bare
>>
On Aug 24, 2005, at 11:10 AM, Guido van Rossum wrote:
> On 8/24/05, Michael Chermside <[EMAIL PROTECTED]> wrote:
>
>> Explicit is better than Implicit. I think that in newly written code
>> "except Exception:" is better (more explicit and easier to
>> understand)
>> than "except:" Legacy code t
On Aug 24, 2005, at 9:39 PM, Brett Cannon wrote:
> On 8/24/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> On 8/24/05, James Y Knight <[EMAIL PROTECTED]> wrote:
>>> I think it must be the case that raising an object which does not
>>> derive from an exc
On Aug 31, 2005, at 5:00 PM, Robert Kern wrote:
> IMO, if we are going to restrict Python 3000 enough to protect that
> "common subset," then there's not enough payoff to justify breaking
> *any* backwards compatibility. If my current codebase[1] isn't
> going to
> be supported in Python 3000, I
On Aug 31, 2005, at 10:21 PM, [EMAIL PROTECTED] wrote:
>
> Tim> One of the big disadvantages of string views is that they
> need to
> Tim> keep the original object around, no matter how big it is.
> But in
> Tim> the case of partition, much of the time the original string
> Ti
On Sep 3, 2005, at 11:32 AM, Barry Warsaw wrote:
> So I think it's best to have two builtins:
>
> print(*args, **kws)
> printf(fmt, *args, **kws)
It seems pretty bogus to me to add a second builtin just to apply the
% operator for you. I've always really liked that Python doesn't have
separa
On Sep 4, 2005, at 12:51 PM, Barry Warsaw wrote:
> On Sat, 2005-09-03 at 12:51, James Y Knight wrote:
>
>> On Sep 3, 2005, at 11:32 AM, Barry Warsaw wrote:
>>
>>
>>> So I think it's best to have two builtins:
>>>
>>> print(*args, **kws)
On Sep 10, 2005, at 6:07 PM, Lisandro Dalcin wrote:
> I had that in mind when I wrote my post; changing types is not the
> way, that will not work. That is why I proposed __future__ (I really
> do not know very well the implementation details of that feature)
> because I think the parser/compiler
On Sep 11, 2005, at 11:24 AM, Guido van Rossum wrote:
> But it breaks the desire to keep the Python 3.0 language clean from
> deprecated features.
That is a nice goal, another nice goal is to not unnecessarily break
things.
> But just installing python3.0 as python and expecting
> nothing will
On Sep 28, 2005, at 9:12 AM, Reinhold Birkenfeld wrote:
> Hi,
>
> a general question. Consider:
>
> class A(list):
> def __setitem__(self, index, item):
> # do something with index and item
> return list.__setitem__(self, index, item)
>
> lst = A([1,set()])
>
> lst[0] |= 1
>
>
On Oct 3, 2005, at 3:47 PM, Fredrik Lundh wrote:
> Antoine Pitrou wrote:
>
>
If I have an unicode string containing legal characters greater
than
0x7F, and I pass it to a function which converts it to str, the
conversion fails.
>>>
>>> so? if it does that, it's not unico
On Oct 3, 2005, at 1:53 AM, Piet Delport wrote:
> For generators written in this style, "yield" means "suspend
> execution of the
> current call until the requested result/resource can be provided", and
> "return" regains its full conventional meaning of "terminate the
> current call
> with a g
On Oct 8, 2005, at 9:10 PM, Nick Coghlan wrote:
> So, instead of having "return" automatically map to "raise
> StopIteration"
> inside generators, I'd like to suggest we keep it illegal to use
> "return"
> inside a generator
Only one issue with that: it's _not currently illegal_ to use return
On Nov 9, 2005, at 6:05 PM, Brett Cannon wrote:
> I would have no issue with removing .pyo files and have .pyc files
> just be as optimized as they the current settings are and leave it at
> that. Could have some metadata listing what optimizations occurred,
> but do we really need to have a s
On Nov 13, 2005, at 8:07 PM, Greg Ewing wrote:
> Ian Bicking wrote:
>
>
>> I think a better argument for this is that dedenting a literal
>> string is
>> more of a syntactic operation than a functional one. You don't think
>> "oh, I bet I'll need to do some dedenting on line 200 of this
>> m
On Dec 5, 2005, at 8:46 AM, Jeremy Hylton wrote:
> On 12/5/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
>> Jeremy Hylton wrote:
>> I would expect that you allocate in the process memory that needs to
>> outlive the arena, e.g. python strings. The fundamental problem is
>> that
>> the aren
On Dec 26, 2005, at 11:07 AM, Martin Blais wrote:
>> Then there's the whole Python list with append() and pop(). It
>> takes a
>> method resolution and function call, but at least in Python 2.3,
>> it is a
>> hair faster...
>
> Josiah, that's beside the point, because it is not space-efficien
On Jan 8, 2006, at 1:01 PM, Martin v. Löwis wrote:
> Fred L. Drake, Jr. wrote:
>
>> I like the way trial (from twisted) supports this. The test
>> method is written
>> normally, in whatever class makes sense. Then the test is marked
>> with an
>> attribute to say it isn't expected to pass y
On Jan 18, 2006, at 11:40 PM, Aahz wrote:
> On Wed, Jan 18, 2006, Guido van Rossum wrote:
>>
>> Can we just all agree that RMS is an asshole now? Bah.
>
> "Citing RMS's insanity is a great way to get my blood steaming." --
> GvR
Ya know, you don't *have* to use his software. For example, pytho
On Jan 19, 2006, at 4:24 PM, Thomas Heller wrote:
>
> Several of these files are licensed under GPL:
>
> aclocal.m4 config-ml.in config.guess config.sub depcomp ltcf-c.sh
> ltconfig missing
>
Are you sure? The copies of aclocal.m4 and config-ml.in both disagree
with you. aclocal seems to have
On Jan 26, 2006, at 7:29 AM, Thomas Heller wrote:
>> And licenses are fluid, it may be a piece of cake to
>> get one of those 'tools' un-GPL'ed, even if they are.
>
> I wouldn't even know whom to ask.
On Jan 26, 2006, at 9:22 AM, Ronald Oussoren wrote:
> It shouldn't be too hard to use Python's
On Jan 31, 2006, at 8:16 PM, Tim Peters wrote:
> [Thomas Wouters]
>> I noticed a few compiler warnings, when I compile Python on my
>> amd64 with
>> gcc 4.0.3:
>>
>> Objects/longobject.c: In function 'PyLong_AsDouble':
>> Objects/longobject.c:655: warning: 'e' may be used uninitialized
>> in
On Feb 1, 2006, at 7:33 AM, Gustavo J. A. M. Carneiro wrote:
> Another possility is to extend the 0x syntax to non-hex,
>
>0xff # hex
>0o644 # octal
>0b1101 # binary
+1
James
___
Python-Dev mailing list
Python-Dev@python.org
http://ma
On Feb 2, 2006, at 7:11 PM, Bengt Richter wrote:
> [1] To reduce all this eye-glazing discussion to a simple example,
> how do people now
> use hex notation to define an integer bit-mask constant with bits
> 31 and 2 set?
That's easy:
0x8004
That was broken in python < 2.4, though, so the
On Feb 2, 2006, at 10:36 PM, Bengt Richter wrote:
> So long as we have a distinction between int and long, IWT int will
> be fixed width
> for any given implementation, and for interfacing with foreign
> functions it will
> continue to be useful at times to limit the type of arguments being
>
201 - 283 of 283 matches
Mail list logo
