Re: [Python-Dev] [Python-3000] Sky pie: a "var" keyword

[Nick Coghlan]

Nick Coghlan wrote:
> Any proposal such as this also needs to addresses all of the *other* name 
> binding statements in Python:
> 
>try/except
>for loop
>with statement
>def statement
>class statement

I forgot the import statement (especially the * version)

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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-3000] Sky pie: a "var" keyword

[Fredrik Lundh]

> I forgot the import statement (especially the * version)

not only that, you also forgot what mailing list you were posting to...

 



___
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] Proprietary code in python?

[Neal Becker]

http://www.google.com/codesearch?q=+doc:DxlBcBw4TXo+proprietary+confidential+show:DxlBcBw4TXo:BwgQSUaGDCc:1s0hP8rbIGE&sa=N&cd=1&ct=ri&cs_p=http://www.python.org/download/releases/binaries-1.3/python-IRIX-5.3-full.tar.gz&cs_f=lib/python/irix5/AWARE.py#a0

___
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] Proprietary code in python?

[Nick Coghlan]

Neal Becker wrote:
> http://www.google.com/codesearch?q=+doc:DxlBcBw4TXo+proprietary+confidential+show:DxlBcBw4TXo:BwgQSUaGDCc:1s0hP8rbIGE&sa=N&cd=1&ct=ri&cs_p=http://www.python.org/download/releases/binaries-1.3/python-IRIX-5.3-full.tar.gz&cs_f=lib/python/irix5/AWARE.py#a0

That file isn't there any more [1]

The file appears to have been removed with the change in license for Python 
2.0 (the last tag I can find containing that file is related 1.5.2). (Note 
that the linked version is Python 1.3)

Cheers,
Nick.

[1] http://svn.python.org/view/python/trunk/Lib/plat-irix5/

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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] Proprietary code in python?

[Fredrik Lundh]

"Neal Becker" <[EMAIL PROTECTED]> wrote:

> http://www.google.com/codesearch?q=+doc:DxlBcBw4TXo+proprietary+confidential+show:DxlBcBw4TXo:BwgQSUaGDCc:1s0hP8rbIGE&sa=N&cd=1&ct=ri&cs_p=http://www.python.org/download/releases/binaries-1.3/python-IRIX-5.3-full.tar.gz&cs_f=lib/python/irix5/AWARE.py#a0

that's most likely code that's been automatically generated from corresponding
header files in IRIX.

in most jurisdictions, laws about corporate secrets doesn't apply to things that
you've intentionally published.  (their file is still copyrighted, but I'm not 
sure to
what extent you can use copyright to protect a few integers).

 



___
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] BUG (urllib2) Authentication request header is broken on long usernames and passwords

[The Doctor What]

Aahz wrote:
> On Mon, Oct 09, 2006, The Doctor What wrote:
>> I found a bug in urllib2's handling of basic HTTP authentication.
> 
> Please submit your bug to SourceForge, then (optional) post the bug
> number back here.
> 
> See http://www.python.org/dev/faq/#bugs

Thank you!  I couldn't find the bug system for python (never had to
submit a bug before) and was looking all over the python.org site.

I see someone else submitted the bug as 1574068.

Ciao!

-- 
I'd horsewhip you if I had a horse.
-- Groucho Marx

The Doctor What: Da Man
http://docwhat.gerf.org/
docwhat *at* gerf *dot* org
KF6VNC
___
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] DRAFT: python-dev summary for 2006-08-16 to 2006-08-31

[Steven Bethard]

Here's the draft summary for the second half of August.  As always,
comments and corrections are greatly appreciated!


=
Announcements
=

---
Python communnity buildbots
---

Want to make sure your package works with the latest and greatest
development and release versions of Python? Thanks to Grig Gheorghiu,
you can add your test suite to the `Python community buildbots`_ and
the results of these tests will show up on the `Python buildbot
results page`_.

.. _Python community buildbots: http://www.pybots.org/
.. _Python buildbot results page: http://www.python.org/dev/buildbot/

Contributing thread:

- `link to community buildbot?
`__


=
Summaries
=

-
Fast subclass testing
-

Neal Norwitz was playing around with a patch that would make subclass
testing for certain builtin types faster by stealing some bits from
tp_flags. Georg Brandl thought this could be useful for exception
handling in Python 3000 when all exceptions must be subclasses of
BaseException. Guido also liked the patch and suggested it be checked
into the `Python 3000 branch`_.

.. _Python 3000 branch: http://svn.python.org/view/python/branches/p3yk/

Contributing thread:

- `Type of range object members
`__

-
gcc 4.2 and integer overflows
-

Jack Howarth pointed out that intobject.c was using the test ``x < 0
&& x == -x`` to determine if the signed integer ``x`` was the most
negative integer on the platform. However, the C standard says
overflow is undefined, so despite this code actually working on pretty
much all known hardware, `gcc 4.2 assumes that overflow won't happen`_
and so optimizes away the entire clause. David Hopwood and Tim Peters
provided a patch that casts ``x`` to an unsigned long (the
"unnecessary" ``0`` is to make the Microsoft compilers happy)::

``x < 0 && (unsigned long)x == 0-(unsigned long)x``

.. _gcc 4.2 assumes that overflow won't happen: http://bugs.python.org/1545668

Contributing thread:

- `gcc 4.2 exposes signed integer overflows
`__

--
Python and 64-bit machines
--

Thomas Heller explained that the _ctypes extension module was still a
fair ways from building on Win64 and had to be removed from the
installer for that platform. There was some discussion about in
general how "experimental" the Win64 build of Python was, but Martin
v. Löwis explained that despite the compiler warnings, Python has been
running mostly fine on Win64 since version 2.4. In fact, Python has
been running in 64-bit machines since 1993 (when Tim Peters ported it
to 64-bit Crays) though of course not with the support that Python 2.5
brought through the Py_ssize_t changes.

Contributing thread:

- `ctypes and win64
`__

--
Guidelines for submitting bugs and patches
--

Brett Cannon put together a rewrite of the `bug and patch
guidelines`_.  The bug guidelines now includes sections on how to:

* Get a SourceForge account
* Start a new bug
* Specify the Python version
* Specify special settings for your Python interpreter
* Give sample code to reproduce bug
* Submit!
* Respond to requests from developers

And the patch guidelines now includes sections on how to:

* Read the Developer Intro to understand the scope of your proposed change
* Add the appropriate unit tests
* Add the proper document changes
* Make your code follow the style guidelines
* Generate a patch
* Create a tracker item on SourceForge
* Reference the patch in proper bug reports
* Wait for a developer to contact you

At Chad Whitacre's suggestion, Brett also included a section on the
5-for-1 rule, where some python-devvers have agreed to review your one
patch if you post reviews of five others.

The updates had not been posted to python.org at the time of this summary.

.. _bug and patch guidelines: http://www.python.org/dev/patches/

Contributing threads:

- `draft for bug guidelines
`__
- `draft of patch guidelines
`__

-
Corner cases for continue/finally
-

Dino Viehland pointed out an odd corner case with ``continue`` in a
``finally`` clause that was causing Python to crash::

for abc in range(10):
try: pass
finally:
try:
continue
except:
pass

The bug was present at least all the way back to Python 2.3. People
t

Re: [Python-Dev] Cloning threading.py using proccesses

[Josiah Carlson]

"Richard Oudkerk" <[EMAIL PROTECTED]> wrote:
> I am not sure how sensible the idea is, but I have had a first stab at
> writing a module processing.py which is a near clone of threading.py
> but uses processes and sockets for communication.  (It is one way of
> avoiding the GIL.)

On non-windows platforms, you should check on unix domain sockets, I've
found they can run a couple times faster than standard sockets on the
local machine.  And if you are using fork or a variant of subprocess to
start processes on linux or Windows, you should consider using pipes,
they can be competitive with sockets (though using a bunch on Windows
can be a pain).

> I have tested it on unix and windows and it seem to work pretty well.
> (Getting round the lack of os.fork on windows is a bit awkward.)
> There is also another module dummy_processing.py which has the same
> api but is just a wrapper round threading.py.
> 
> Queues, Locks, RLocks, Conditions, Semaphores and some other shared
> objects are implemented.
> 
> People are welcome to try out the tests in test_processing.py
> contained in the zipfile.  More information is included in the README
> file.
> 
> As a quick example, the code

[snip]

Looks interesting.  Maybe it would become clearer with docs (I hope
you've written some).  Right now there is a difference, and it is
basically that there are tokens and proxies, which could confuse some
users.

Presumably with this library you have created, you have also written a
fast object encoder/decoder (like marshal or pickle).  If it isn't any
faster than cPickle or marshal, then users may bypass the module and opt
for fork/etc. + XML-RPC; which works pretty well and gets them
multi-machine calling, milti-language interoperability, and some other
goodies, though it is a bit slow in terms of communication.


 - Josiah

___
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] Cloning threading.py using proccesses

[Fredrik Lundh]

Josiah Carlson wrote:

> Presumably with this library you have created, you have also written a
> fast object encoder/decoder (like marshal or pickle).  If it isn't any
> faster than cPickle or marshal, then users may bypass the module and opt
> for fork/etc. + XML-RPC

XML-RPC isn't close to marshal and cPickle in performance, though, so 
that statement is a bit misleading.

the really interesting thing here is a ready-made threading-style API, I 
think.  reimplementing queues, locks, and semaphores can be a reasonable 
amount of work; might as well use an existing implementation.



___
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] BRANCH FREEZE, release24-maint for 2.4.4c1. 00:00UTC, 11 October 2006

[Anthony Baxter]

The release24-maint branch is frozen for the 2.4.4c1 release from 00:00UTC on 
the 11th of October. That's about 7 hours from now.

Anthony
-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
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] 2.4 vs Windows vs bsddb

[Gregory P. Smith]

On Mon, Oct 09, 2006 at 08:11:59PM -0400, Tim Peters wrote:
> [Tim]
> > I just noticed that the bsddb portion of Python fails to compile on
> > the 2.4 Windows buildbots, but for some reason the buildbot machinery
> > doesn't notice the failure:
> 
> But it does now.  This is the revision that broke the Windows build:
> 
> """
> r52170 | andrew.kuchling | 2006-10-05 14:49:36 -0400 (Thu, 05 Oct
> 2006) | 12 lines
> 
> [Backport r50783 | neal.norwitz.  The bytes_left code is complicated,
>  but looks correct on a casual inspection and hasn't been modified
>  in the trunk.  Does anyone want to review further?]
> 
> Ensure we don't write beyond errText.  I think I got this right, but
> it definitely could use some review to ensure I'm not off by one
> and there's no possible overflow/wrap-around of bytes_left.
> Reported by Klocwork #1.
> 
> Fix a problem if there is a failure allocating self->db.
> Found with failmalloc.
> """
> 
> It introduces uses of assert() and strncat(), and the linker can't
> resolve them.  I suppose that's because the Windows link step for the
> _bsddb subproject explicitly excludes msvcrt (in the release build)
> and msvcrtd (in the debug build), but I don't know why that's done.
> 
> OTOH, we got a lot more errors (about duplicate code definitions) if
> the standard MS libraries aren't explicitly excluded, so that's no
> fix.

It seems bad form to C assert() within a python extension.  crashing
is bad.  Just code it to not copy the string in that case.  The
exception type should convey enough info alone and if someone actually
looks at the string description of the exception they're welcome to
notice that its missing info and file a bug (it won't happen; the
strings come from the BerkeleyDB or C library itself).

As for the strncat instead of strcat that is good practice.  The
buffer is way more than large enough for any of the error messages
defined in the berkeleydb common/db_err.c db_strerror() function but
the C library could supply its own unreasonably long one in some
unforseen circumstance.

-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] 2.4 vs Windows vs bsddb

[Tim Peters]

[Gregory P. Smith]
> It seems bad form to C assert() within a python extension.  crashing
> is bad.  Just code it to not copy the string in that case.  The
> exception type should convey enough info alone and if someone actually
> looks at the string description of the exception they're welcome to
> notice that its missing info and file a bug (it won't happen; the
> strings come from the BerkeleyDB or C library itself).

The proper use of C's assert() in Python (whether core or extension)
is to strongly document a condition the author believes /must/ be
true.  It's a strong sanity-check on the programmer's beliefs about
necessary invariants, things that must be true under all possible
conditions.  For example, it would always be wrong to assert that the
result of calling malloc() with a non-zero argument is non-NULL; it
would be correct (although trivially and unhelpfully so) to assert
that the result is NULL or is not NULL.

Given that, the assert() in question looks fine to me:

if (_db_errmsg[0] && bytes_left < (sizeof(errTxt) - 4)) {
bytes_left = sizeof(errTxt) - bytes_left - 4 - 1;
assert(bytes_left >= 0);

We can't get into the block unless

bytes_left < sizeof(errTxt) - 4

is true.  Subtracting bytes_left from both sides, then swapping LHS and RHS:

sizeof(errTxt) - bytes_left - 4 > 0

which implies

sizeof(errTxt) - bytes_left - 4 >= 1

Subtracting 1 from both sides:

sizeof(errTxt) - bytes_left - 4 - 1 >= 0

And since the LHS of that is the new value of bytes_left, it must be true that

 bytes_left >= 0

Either that, or the original author (and me, just above) made an error
in analyzing what must be true at this point.  From

bytes_left < sizeof(errTxt) - 4

it's not /instantly/ obvious that

bytes_left >= 0

inside the block, so there's value in assert'ing that it's true.  It's
both documentation and an executable sanity check.

In any case, assert() statements are thrown away in a release build,
so can't be a cause of abnormal termination then.

> As for the strncat instead of strcat that is good practice.  The
> buffer is way more than large enough for any of the error messages
> defined in the berkeleydb common/db_err.c db_strerror() function but
> the C library could supply its own unreasonably long one in some
> unforseen circumstance.

That's fine -- there "shouldn't have been" a problem with using any
standard C function here.  It was just the funky linker step on
Windows on the 2.4 branch that was hosed.  Martin figured out how to
repair it, and there's no longer any problem here.  In fact, even the
been-there-forever linker warnings in 2.4 on Windows have gone away
now.
___
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] 2.4.4: backport classobject.c HAVE_WEAKREFS?

[Armin Rigo]

Hi Raymond,

On Fri, Oct 06, 2006 at 08:48:15AM -0700, Raymond Hettinger wrote:
> No need to backport.  Py_TPFLAGS_DEFAULT implies
> Py_TPFLAGS_HAVE_WEAKREFS.
> 
> 
> The change was for clarity -- most things that have the weakref slots
> filled-in will also make the flag explicit -- that makes it easier on
> the brain when verifying code that checks the weakref flag.

I don't understand why you added this flag here; there are many other
flags with a meaning very similar to Py_TPFLAGS_HAVE_WEAKREFS, which are
also implied by Py_TPFLAGS_DEFAULT.  Also, *all* other types in a
CPython build use Py_TPFLAGS_DEFAULT as well, so have
Py_TPFLAGS_HAVE_WEAKREFS set.  Why would explicitly spelling just this
flag, on just this type, help make the overall code clearer?  It seems
to only further confuse the matter -- the slightly obscure bit that
requires some getting used to is that all these flags don't really mean
"I have such and such feature" but just "I could have such and such
feature, if the corresponding tp_xxx field were set".


A bientot,

Armin
___
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] Cloning threading.py using proccesses

[Josiah Carlson]

Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> 
> Josiah Carlson wrote:
> 
> > Presumably with this library you have created, you have also written a
> > fast object encoder/decoder (like marshal or pickle).  If it isn't any
> > faster than cPickle or marshal, then users may bypass the module and opt
> > for fork/etc. + XML-RPC
> 
> XML-RPC isn't close to marshal and cPickle in performance, though, so 
> that statement is a bit misleading.

You are correct, it is misleading, and relies on a few unstated
assumptions.

In my own personal delving into process splitting, RPC, etc., I usually
end up with one of two cases; I need really fast call/return, or I need
not slow call/return.  The not slow call/return is (in my opinion)
satisfactorally solved with XML-RPC.  But I've personally not been
satisfied with the speed of any remote 'fast call/return' packages, as
they usually rely on cPickle or marshal, which are slow compared to
even moderately fast 100mbit network connections.  When we are talking
about local connections, I have even seen cases where the
cPickle/marshal calls can make it so that forking the process is faster
than encoding the input to a called function.

I've had an idea for a fast object encoder/decoder (with limited support
for certain built-in Python objects), but I haven't gotten around to
actually implementing it as of yet.


> the really interesting thing here is a ready-made threading-style API, I 
> think.  reimplementing queues, locks, and semaphores can be a reasonable 
> amount of work; might as well use an existing implementation.

Really, it is a matter of asking what kind of API is desireable.  Do we
want to have threading plus other stuff be the style of API that we want
to replicate?  Do we want to have shared queue objects, or would an
XML-RPC-esque remote.queue_put('queue_X', value) and
remote.queue_get('queue_X', blocking=1) be better?


 - Josiah

___
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] 2.4.4: backport classobject.c HAVE_WEAKREFS?

[Raymond Hettinger]

> The change was for clarity -- most things that have the weakref slots
> filled-in will also make the flag explicit -- that makes it easier on
> the brain when verifying code that checks the weakref flag.

> I don't understand why you added this flag here;

Perhaps my other post wasn't clear.  The change wasn't necessary, so if
it bugs you, feel free to take it out.  Essentially, it was a "note to
self" so that I didn't have to keep looking up what was implied by
Py_TPFLAGS_DEFAULT.

> the slightly obscure bit that requires some getting used to is 
> that all these flags don't really mean "I have such and such 
> feature" but just "I could have such and such
> feature, if the corresponding tp_xxx field were set".

I would like to see that cleaned-up for Py3k.  Ideally, the NULL or
non_NULL status of a slot should serve as its flag.


Raymond
___
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] 2.4.4: backport classobject.c HAVE_WEAKREFS?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Oct 10, 2006, at 5:47 PM, Raymond Hettinger wrote:

>> the slightly obscure bit that requires some getting used to is
>> that all these flags don't really mean "I have such and such
>> feature" but just "I could have such and such
>> feature, if the corresponding tp_xxx field were set".
>
> I would like to see that cleaned-up for Py3k.  Ideally, the NULL or
> non_NULL status of a slot should serve as its flag.

+1 TOOWTDI.

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRSwjRHEjvBPtnXfVAQJ0sQQAllzbSdONhCBWc/Rt0PW6J5iANLcm99N4
MkkSEDZBo72SsviijRvTha1+1pvpzB6s4Rf7EOw/OKnQ+a3u37w3BB966ag8WIN1
RItKubCVS6kTpg53BBnIX7P0CGSFFY36pEQm4nNe3G6RH4F0FwmIdv0WyJhSnnDR
KRT9PHI9QY8=
=bH9r
-END PGP SIGNATURE-
___
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] 2.4 vs Windows vs bsddb

[David Hopwood]

Tim Peters wrote:
> Given that, the assert() in question looks fine to me:
> 
> if (_db_errmsg[0] && bytes_left < (sizeof(errTxt) - 4)) {
> bytes_left = sizeof(errTxt) - bytes_left - 4 - 1;
> assert(bytes_left >= 0);
> 
> We can't get into the block unless
> 
> bytes_left < sizeof(errTxt) - 4
> 
> is true.  Subtracting bytes_left from both sides, then swapping LHS and RHS:
> 
> sizeof(errTxt) - bytes_left - 4 > 0
> 
> which implies
> 
> sizeof(errTxt) - bytes_left - 4 >= 1
> 
> Subtracting 1 from both sides:
> 
> sizeof(errTxt) - bytes_left - 4 - 1 >= 0
> 
> And since the LHS of that is the new value of bytes_left, it must be true that
> 
>  bytes_left >= 0
> 
> Either that, or the original author (and me, just above) made an error
> in analyzing what must be true at this point.

You omitted to state an assumption that sizeof(errTxt) >= 4, since size_t
(and the constant 4) are unsigned. Also bytes_left must initially be nonnegative
so that the subexpression 'sizeof(errTxt) - bytes_left' cannot overflow.

-- 
David Hopwood <[EMAIL PROTECTED]>


___
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] 2.4 vs Windows vs bsddb [correction]

[David Hopwood]

I wrote:
> You omitted to state an assumption that sizeof(errTxt) >= 4, since size_t
> (and the constant 4) are unsigned.

Sorry, the constant '4' is signed, but sizeof(errTxt) - 4 can nevertheless
wrap around unless sizeof(errTxt) >= 4.

-- 
David Hopwood <[EMAIL PROTECTED]>


___
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] 2.4 vs Windows vs bsddb

[Tim Peters]

[Tim]
>> Given that, the assert() in question looks fine to me:
>> ...
|>> Either that, or the original author (and me, just above) made an error
>>  in analyzing what must be true at this point.
|

[David Hopwood]
> You omitted to state an assumption that sizeof(errTxt) >= 4, since size_t
> (and the constant 4) are unsigned. Also bytes_left must initially be 
> nonnegative
> so that the subexpression 'sizeof(errTxt) - bytes_left' cannot overflow.

I don't care, but that's really the /point/:  asserts are valuable
precisely because any inference that's not utterly obvious at first
glance at best stands a good chance of relying on hidden assumptions.
assert() makes key assumptions and key inferences visible, and
verifies them in a debug build of Python.
___
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] 2.4.4: backport classobject.c HAVE_WEAKREFS?

[Martin v. Löwis]

Raymond Hettinger schrieb:
>> the slightly obscure bit that requires some getting used to is 
>> that all these flags don't really mean "I have such and such 
>> feature" but just "I could have such and such
>> feature, if the corresponding tp_xxx field were set".
> 
> I would like to see that cleaned-up for Py3k.  Ideally, the NULL or
> non_NULL status of a slot should serve as its flag.

The flag indicates that the field is even present. If you have
an extension module from an earlier Python release (in binary
form), it won't *have* the field, so you can't test whether it's
null. Accessing it will get to some other place in the data
segment, and interpreting it as a function pointer will cause
a crash. That's why the flags where initially introduced;
presence of the flag indicates that the field was there at
compile time.

Of course, if everybody would always recompile all extension modules
for a new Python feature release, those flags weren't necessary.

Regards,
Martin
___
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