[Python-Dev] pep3118, ctypes, py3k

2008-01-30 Thread Thomas Heller 
Hi Travis,

I have started the pep3118 implementation for ctypes.  If you have time,
could you please review , especially
the tests in file Lib/ctypes/test/test_pep3118.py to ensure that I have
understood and implemented the pep correctly?

Thanks,
Thomas
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] ctypes issue

2008-01-30 Thread Neal Becker 
In python 2.5.1:

from ctypes import *
c = c_int(4)
print c == 4
print c.value == 4

False
True

This seem unreasonable to me, and a big invitation to error.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Upcoming 2.5.2 release

2008-01-30 Thread Jesus Cea 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin v. Löwis wrote:
| It is my pleasure to announce that I have been appointed as the release
| manager for the upcoming releases. For 2.5.2, I would like to release
| a candidate on February 14, and the final version on February 21. As
| Guido already mentioned, this will be a bug fix release only; no new
| features allowed.

As current bsddb module maintainer, I was wondering if 2.5.2 will
support BerkeleyDB 4.6 :-?.

- --
Jesus Cea Avion _/_/  _/_/_/_/_/_/
[EMAIL PROTECTED] http://www.argo.es/~jcea/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/  _/_/_/_/_/
~   _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBR6B+jZlgi5GaxT1NAQIX+QQAl7PFJtZb64kiTpewupJppos5mAXFKB29
lrud1t6AkgFOgvE9M45ISCwTDzbSa4qLOiDX/v5F9RltcH+RK5Tlu3eTR8Djmn6q
PSzjo92LZx7wudq2WaBL2+PIE/IhAOO9gKHtwNtB3iXQGTl8NKIIJUbkDUclvPPv
bH97ECQvb7U=
=yV47
-END PGP SIGNATURE-
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TIOBE Programming Community Index

2008-01-30 Thread Jesus Cea 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Steve Holden wrote:
|> Sorry if this is a repeat.

Published also in Slashdot.

- --
Jesus Cea Avion _/_/  _/_/_/_/_/_/
[EMAIL PROTECTED] http://www.argo.es/~jcea/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/  _/_/_/_/_/
~   _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBR6B9+plgi5GaxT1NAQIWIAP+L0CZdJedSywHWR6h0+tcRQrtmgVRfYH1
WA1PoWBqcP943rYENfK/fiaEh/D+QSrDVDcWktfN+sAP+9UuBkMb0euM4NEtdbqt
K4ow+N2By6quBNKey/S2Ngr0cgnCk45B1UstD63S72+dtOvJ9bIBn1XMEhu7ANzJ
MPhvHZBtqGY=
=201s
-END PGP SIGNATURE-
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Assigning issues

2008-01-30 Thread Jesus Cea 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I just trying to open a new bug in bssdb module and assign it to me :-).
Seems I have no permissions to do that :-).

The issue is http://bugs.python.org/issue1976

- --
Jesus Cea Avion _/_/  _/_/_/_/_/_/
[EMAIL PROTECTED] http://www.argo.es/~jcea/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/  _/_/_/_/_/
~   _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBR6CqkJlgi5GaxT1NAQJ4VAQAoa7FGC7OxeNiQUDKsjaZ9Q6gtOBXtuJp
0O31VllV82eINCKU2BA/XAHTik/CxvvVRPjLElumln3Lccj++8IVeSgHoPntDZuc
7kJhrD+OZXTPWkV4/g+sgepycF+wNr2ICM2o75ABz2CuyXNYmLum0fH7UPUORi+U
V921rj9Kzss=
=0Soy
-END PGP SIGNATURE-
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Upcoming 2.5.2 release

2008-01-30 Thread Martin v. Löwis 
> | It is my pleasure to announce that I have been appointed as the release
> | manager for the upcoming releases. For 2.5.2, I would like to release
> | a candidate on February 14, and the final version on February 21. As
> | Guido already mentioned, this will be a bug fix release only; no new
> | features allowed.
> 
> As current bsddb module maintainer, I was wondering if 2.5.2 will
> support BerkeleyDB 4.6 :-?.

Maybe I'm misunderstanding the question - whom are asking?
If me - Python 2.5.2 will essentially do what the maintenance branch
does currently.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Assigning issues

2008-01-30 Thread Brett Cannon 
On Jan 30, 2008 8:49 AM, Jesus Cea <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I just trying to open a new bug in bssdb module and assign it to me :-).
> Seems I have no permissions to do that :-).
>
> The issue is http://bugs.python.org/issue1976
>

We have not worked out any policy on this, but I always assumed we
would only assign issues to people with commit privileges. I quick
check suggests that you don't have them, Jesus. We can give you the
rights to modify issues and set the assignment, but I don't know if
you should be able to be assigned a bug yet.

What do other people think?

-Brett


> - --
> Jesus Cea Avion _/_/  _/_/_/_/_/_/
> [EMAIL PROTECTED] http://www.argo.es/~jcea/ _/_/_/_/  _/_/_/_/  _/_/
> jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/  _/_/_/_/_/
> ~   _/_/  _/_/_/_/  _/_/  _/_/
> "Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
> "My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iQCVAwUBR6CqkJlgi5GaxT1NAQJ4VAQAoa7FGC7OxeNiQUDKsjaZ9Q6gtOBXtuJp
> 0O31VllV82eINCKU2BA/XAHTik/CxvvVRPjLElumln3Lccj++8IVeSgHoPntDZuc
> 7kJhrD+OZXTPWkV4/g+sgepycF+wNr2ICM2o75ABz2CuyXNYmLum0fH7UPUORi+U
> V921rj9Kzss=
> =0Soy
> -END PGP SIGNATURE-
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Assigning issues

2008-01-30 Thread Nick Coghlan 
Brett Cannon wrote:
> On Jan 30, 2008 8:49 AM, Jesus Cea <[EMAIL PROTECTED]> wrote:
>> I just trying to open a new bug in bssdb module and assign it to me :-).
>> Seems I have no permissions to do that :-).
> 
> We have not worked out any policy on this, but I always assumed we
> would only assign issues to people with commit privileges. I quick
> check suggests that you don't have them, Jesus. We can give you the
> rights to modify issues and set the assignment, but I don't know if
> you should be able to be assigned a bug yet.
> 
> What do other people think?

Given that everyone is free to work on whichever issues are of interest 
to them (and post comments to the relevant tracker items), I've always 
seen the assignment field as a way to request that a specific committer 
either fix the problem themselves, or review a proposed solution and 
either suggest improvements or check it in.

I think you're right that there isn't really an official policy written 
down anywhere though - PEP 3 doesn't go into that kind of detail.

Cheers,
Nick.


-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Monkeypatching idioms -- elegant or ugly?

2008-01-30 Thread Kevin Teague 
+1 on having established Python idioms for these techniques.

While I don't know if there has ever been a formal definition of  
monkey patch, the term monkey patch came from guerilla patch, which  
came from two or more dynamic modifications to a class interfering  
with each other. These modifications were usually made by extension  
code (Zope add-on Products) to upstream code (the Zope framework), so  
I would define a monkey patch only as dynamic modifications made to a  
class with the *intent to change or correct behaviour in upstream code*.

The term has also caught on with the a second definition of referring  
to any dynamic modification of class, regardless of intent though.

I would perhaps call these methods something like:

  * add_method_to_class

  * extend_class

This gives you a better idea of what they do, rather than use a term  
with a somewhat ambigous definition. With monkeypatch_method under the  
definition of "altering existing upstream behviour", I might expect it  
to raise an error if the method I was replacing on a class did not  
exist (e.g. upstream code was refactored so my patch no longer applied).


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Assigning issues

2008-01-30 Thread Martin v. Löwis 
> We have not worked out any policy on this, but I always assumed we
> would only assign issues to people with commit privileges. I quick
> check suggests that you don't have them, Jesus. We can give you the
> rights to modify issues and set the assignment, but I don't know if
> you should be able to be assigned a bug yet.
> 
> What do other people think?

That has exactly been the policy that I have been executing, yes.

As for giving additional rights on a per-user basis - that's tricky
to implement. We have the User and Developer roles in the tracker,
and you get additional rights only with additional roles, normally.

I also agree with Nick as to what the purpose of assignments is.
To indicate that you are working on a specific issue, a message
saying so is enough (which could also include estimated completion
dates, which a mere self-assignment can't).

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adventures with x64, VS7 and VS8 on Windows

2008-01-30 Thread Mark Hammond 
I'm wondering if anyone has any comment on this issue?  Its currently
impossible to use distutils as documented to build x64 extensions, either
natively or cross-compiled using the trunk and while I'm keen to help fix
this, I'd like agreement on the direction.

Can I assume silence means general agreement on the compromise proposal I
outlined?

Thanks,

Mark
 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Mark Hammond
> Sent: Tuesday, 22 January 2008 9:06 PM
> To: '"Martin v. Löwis"'
> Cc: [EMAIL PROTECTED]; [email protected]
> Subject: Re: [Python-Dev] Adventures with x64, VS7 and VS8 on Windows
> 
> Hi Martin,
> 
> Way back on Monday, 21 May 2007, you wrote:
> 
> > This is an issue to be discussed for Python 2.6. I'm personally
> > hesitant to have the "official" build infrastructure deviate
> > from the layout that has been in-use for so many years, as a lot
> > of things depend on it.
> >
> > I don't find the need to have separate object directories convincing:
> > For building the Win32/Win64 binaries, I have separate checkouts
> > *anyway*, since all the add-on libraries would have to support
> > multi-arch builds, but I think they don't.
> ...
> > > * Re the x64 directory used by the PCBuild8 process.  IMO, it makes
> > > sense to generate x64 binaries to their own directory - my
> expectation
> > > is that cross-compiling between platforms is a reasonable use-case,
> > > and we should support multiple achitectures for the same compiler
> > > version.
> >
> > See above; I disagree.
> 
> [For additional context; the question was regarding where the output
> binaries were created for each platform, and specifically if x64 build
> should use something like 'PCBuild/x64']
> 
> I'm bringing this topic up again as I noticed the AMD64 builds for
> Python
> 2.6 create their output in the PCBuild/x64 directory, not directly into
> the
> PCBuild directory.  When I raised this with Christian, he also
> expressed a
> desire to be able to cross-compile in the same directory structure and
> was
> unaware of this discussion (but I made him aware of it :)
> 
> You made excellent points about how tools currently recognize the
> PCBuild
> directory, and we can't break them, and I agree.  I'd like to propose a
> compromise that might be able to keep everyone happy.
> 
> The main problem I see with all platforms using 'PCBuild' is that in a
> cross-compilation scenario, it is impossible for the distutils to
> determine
> the location of the correct Python libraries to link with (stuff in its
> own
> PYTHONHOME is no good; it's for the wrong platform).  Obviously, we can
> change the distutils so that the location of the correct libraries can
> be
> specified, but that implies all other build systems that currently
> assume
> PCBuild must also change to work in a cross-compilation scenario.
> While
> those external tools *will* work today in a native build on x64,
> eventually
> they may need to be upgraded to deal with cross-compilation - and this
> means
> that all such tools will also be unable to automatically determine the
> location of the libraries.  They will all need to take the library dir
> as a
> user-specified option, which seems a pain (eg, buildbots would seem to
> need
> site-specific configuration information to make this work).  If
> eventually
> all such tools are likely to upgrade, it would be ideal if we can offer
> them
> a way to upgrade so the correct libraries can be determined
> automatically,
> as they can now for native builds.
> 
> My compromise proposal is this: Each platform builds in its own
> directory
> (ie, PCBuild/x86_64, PCBuild/x86).  Every single build configuration
> has a
> post-build step that copies the result of the build to the PCBuild
> directory.  We then add an option to the distutils so that a cross-
> compile
> platform can be specified and when it is, to use 'PCBuild/{platform}"
> instead of PCBuild, and we encourage other tools to use the same
> directory
> should they want to support "configure-less" cross-compilation (if
> distutils
> on the trunk is not still trying to maintain b/w compat, it should just
> *always* look in PCBuild/{platform}, and I'd suggest py3k not bother
> with
> PCBuild at all; build systems will be touched to upgrade to py3k, so
> that
> change isn't painful.  But I digress :)
> 
> The main advantage of the compromise is that it allows for the status
> quo to
> remain in place - just continue to use separate source trees for each
> platform, and only ever build a single platform in each tree, and tools
> are
> free to have ways of specifying which directory should be used.  The
> official build process need not change.  However, it also supports a
> way to
> do cross-compilation in a way that build tools can *automatically*
> locate
> the correct platform's libraries, and this will be particularly useful
> for
> extension authors.
> 
> Would something like that be acceptable?
> 
> Thanks,