Re: [Python-Dev] Unable to commit

[Martin v. Löwis]

Georg Brandl schrieb:
> Martin v. Löwis schrieb:
>>> Odd... the call worked here (SVN 1.4.3). Which version is the server using?
>> 1.1. Subversion did a grand renaming at some point. I fixed most of the
>> functions when deploying the script, but apparently missed some.
> 
> Okay. Is an upgrade planned? I've heard that several actions were sped up
> significantly with later releases.

I have plans for that. However, these plans may take many months to
execute, as one needs to set aside a lot of time to work on the update
of www.python.org continuously, to deal with the aftermath of the Debian
upgrade, and you also need to have desaster plans, which are difficult
with no physical access to the machine (so I need to learn how to get
virtual physical access first).

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

Re: [Python-Dev] whitespace normalization pre-commit hook is giving me grief

[Scott Dial]

Martin v. Löwis wrote:
> Brett Cannon schrieb:
>> Unfortunately the pre-commit hook
>> does not specify what line a change was made on so I have no clue where
>> it is failing (maybe this should be added?).
> 
> It creates a reindent.Reindenter on the new contents, then invokes
> .run() on it, and complains if that returns true. If you can come
> up with a patch to reindent that makes it report more detailed
> errors, please post it, and I'll try to merge it into the hook
> script.
> 

How about you do:

 if reindenter.run():
 print >>sys.stderr, "file %s is not whitespace-normalized" %path
print >>sys.stderr, difflib.unified_diff(reindenter.raw,
  reindenter.after)
 bad += 1

Which would provide you a unified diff to give you a clue.

-- 
Scott Dial
[EMAIL PROTECTED]
[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] whitespace normalization pre-commit hook is giving me grief

[Georg Brandl]

Scott Dial schrieb:
> Martin v. Löwis wrote:
>> Brett Cannon schrieb:
>>> Unfortunately the pre-commit hook
>>> does not specify what line a change was made on so I have no clue where
>>> it is failing (maybe this should be added?).
>> 
>> It creates a reindent.Reindenter on the new contents, then invokes
>> .run() on it, and complains if that returns true. If you can come
>> up with a patch to reindent that makes it report more detailed
>> errors, please post it, and I'll try to merge it into the hook
>> script.
>> 
> 
> How about you do:
> 
>  if reindenter.run():
>  print >>sys.stderr, "file %s is not whitespace-normalized" %path
>   print >>sys.stderr, difflib.unified_diff(reindenter.raw,
>   reindenter.after)
>  bad += 1
> 
> Which would provide you a unified diff to give you a clue.

As I said before, you don't really need that when you can (and should!) just run
reindent.py over the source file yourself, not care about any diffs and just
resubmit.

In this particular case, the diff wouldn't have helped too, since there was no
way to "fix" the SVN-generated file content...

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] whitespace normalization pre-commit hook is giving me grief

[Martin v. Löwis]

> As I said before, you don't really need that when you can (and should!) just 
> run
> reindent.py over the source file yourself, not care about any diffs and just
> resubmit.

Right. So I withdraw my offer to do anything about the hook.

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

Re: [Python-Dev] whitespace normalization pre-commit hook is giving me grief

[Georg Brandl]

Martin v. Löwis schrieb:
>> As I said before, you don't really need that when you can (and should!) just 
>> run
>> reindent.py over the source file yourself, not care about any diffs and just
>> resubmit.
> 
> Right. So I withdraw my offer to do anything about the hook.

I think printing something like "Please run Tools/scripts/reindent.py 
with the rejected files" if bad files were found would be a good idea.

Georg


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] [Distutils] Adventures with x64, VS7 and VS8 on Windows

[Jamie Kirkpatrick]

I recommend that those people install the official binaries. Why do  
you

need to build the binaries from source, if all you want is to build
extensions?



I've been following this discussion and it seems like an appropriate  
place to mention such a scenario which I have encountered myself and  
am still trying to work around:


I have a set of extensions that use SWIG to wrap my own C++ library.   
This library, on a day-to-day basis is built against VS8 since the  
rest of our product suite is.  Right now I have no way to work with  
this code using VS8 since the standard distribution is built against  
VS7 which uses a different CRT.   This is an absolute nightmare in  
practice since I currently have to maintain VS7 projects in parallel  
with the standard VS8 ones simply so that I can run and test my  
python code.


I've downloaded the Python source and had a look at building up my  
own distributions for each case (ideally there would be an easy way  
to separate out Release / Debug products as well as the VS8 / VS7  
variants, and I guess potentially for those cross-compiling we'd need  
to go a step further and do this per arch as well.  Anyway, this  
isn't how it works at the moment, but I'm still searching for a way  
to be able to work on the python code in VS8.  Building using the  
current projects I seem to get everything in the PCBuild8 / PCBuild  
dirs.  How can I work with what is build?


Is there a shell script to build a final distribution tree?  If not,  
is there a simple way to build an MSI similar to the one found on the  
Python.org site for the official releases but using the PCBuild8  
stuff?  If not how do you recommend getting myself to a state where I  
have at least a feature complete distribution build against VS8?  I'm  
happy with a one time build that I can just install into my source  
tree and upload to the SCM.


Thanks in advance, and I hope that my thoughts proved useful in some  
way.


Jamie___
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] Wither PEP 335 (Overloadable Boolean Operators)?

[Neville Grech Neville Grech]

From a user's POV, I'm +1 on having overloadable boolean functions. In many

cases I had to resort to overload add or neg instead of and & not, I foresee
a lot of cases where the and overload could be used to join objects which
represent constraints. Overloadable boolean operators could also be used to
implement other types of logic (eg: fuzzy logic). Constraining them to just
primitive binary operations in my view will be delimiting for a myriad of
use cases.

Sure, in some cases, one could overload the neg operator instead of the not
but semantically they have different meanings.

On 5/25/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:


On 5/24/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > Last call for discussion! I'm tempted to reject this -- the ability to
> > generate optimized code based on the shortcut semantics of and/or is
> > pretty important to me.
>
> Please don't be hasty. I've had to think about this issue
> a bit.
>
> The conclusion I've come to is that there may be a small loss
> in the theoretical amount of optimization opportunity available,
> but not much. Furthermore, if you take into account some other
> improvements that can be made (which I'll explain below) the
> result is actually *better* than what 2.5 currently generates.
>
> For example, Python 2.5 currently compiles
>
>if a and b:
>  
>
> into
>
>  
>  JUMP_IF_FALSE L1
>  POP_TOP
>  
>  JUMP_IF_FALSE L1
>  POP_TOP
>  
>  JUMP_FORWARD L2
>L1:
>  15 POP_TOP
>L2:
>
> Under my PEP, without any other changes, this would become
>
>  
>  LOGICAL_AND_1 L1
>  
>  LOGICAL_AND_2
>L1:
>  JUMP_IF_FALSE L2
>  POP_TOP
>  
>  JUMP_FORWARD L3
>L2:
>  15 POP_TOP
>L3:
>
> The fastest path through this involves executing one extra
> bytecode. However, since we're not using JUMP_IF_FALSE to
> do the short-circuiting any more, there's no need for it
> to leave its operand on the stack. So let's redefine it and
> change its name to POP_JUMP_IF_FALSE. This allows us to
> get rid of all the POP_TOPs, plus the jump at the end of
> the statement body. Now we have
>
>  
>  LOGICAL_AND_1 L1
>  
>  LOGICAL_AND_2
>L1:
>  POP_JUMP_IF_FALSE L2
>  
>L2:
>
> The fastest path through this executes one *less* bytecode
> than in the current 2.5-generated code. Also, any path that
> ends up executing the body benefits from the lack of a
> jump at the end.
>
> The same benefits also result when the boolean expression is
> more complex, e.g.
>
>if a or b and c:
>  
>
> becomes
>
>  
>  LOGICAL_OR_1 L1
>  
>  LOGICAL_AND_1 L2
>  
>  LOGICAL_AND_2
>L2:
>  LOGICAL_OR_2
>L1:
>  POP_JUMP_IF_FALSE L3
>  
>L3:
>
> which contains 3 fewer instructions overall than the
> corresponding 2.5-generated code.
>
> So I contend that optimization is not an argument for
> rejecting this PEP, and may even be one for accepting
> it.

Do you have an implementation available to measure this? In most cases
the cost is not in the number of bytecode instructions executed but in
the total amount of work. Two cheap bytecodes might well be cheaper
than one expensive one.

However, I'm happy to keep your PEP open until you have code that we
can measure. (However, adding additional optimizations elsewhere to
make up for the loss wouldn't be fair -- we would have to compare with
a 2.5 or trunk (2.6) interpreter with the same additional
optimizations added.)

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-3000 mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/nevillegrech%40gmail.com





--
Regards,
Neville Grech
___
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] Adventures with x64, VS7 and VS8 on Windows

[Kristján Valur Jónsson]

> -Original Message-
>
> Microsoft's command line cannot cope with two pathnames that must be
> quoted, so if the command path itself must be quoted, then no argument
> to
> the command can be quoted.  There are tricky hacks that can work around
> this mind-boggling stupidity, but life is simpler if Python itself
> doesn't
> use up the one quoted pathname.  I don't know if Microsoft has had the
> good
> sense to fix this in Vista (which I probably will never use, since an
> alternative exists), but they didn't in XP.

Do you have any references for this claim?
In my command line on XP sp2, this works just fine:

C:\Program Files\Microsoft Visual Studio 8\VC>"c:\Program Files\TextPad 
4\TextPad.exe" "c:\tmp\f a.txt" "c:\tmp\f b.txt"

Both the program, and the two file names are quoted and textpad.exe opens them 
both.

Cheers,
Kristján
___
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] [Distutils] Adventures with x64, VS7 and VS8 on Windows

[Nick Coghlan]

Martin v. Löwis wrote:
>> I have a set of extensions that use SWIG to wrap my own C++ library. 
>> This library, on a day-to-day basis is built against VS8 since the rest
>> of our product suite is.  Right now I have no way to work with this code
>> using VS8 since the standard distribution is built against VS7 which
>> uses a different CRT.   This is an absolute nightmare in practice since
>> I currently have to maintain VS7 projects in parallel with the standard
>> VS8 ones simply so that I can run and test my python code.
> 
> If you know well enough what you are doing, and avoid using unsupported
> cases, you *can* mix different CRTs.

I can attest to this - I have SWIG-wrapped extensions built with VC6 
running quite happily against the official VS7 binaries for Python 2.4. 
Moving from Python 2.2 to Python 2.4 was a simple matter of recompiling 
and relinking the modules.

The important thing was to make sure to never pass memory ownership or 
standard lib data structures across the boundary. I haven't actually 
found this to be all that difficult in practice, as I am typically 
either copying data from standard library data structures into native 
Python data structures (e.g. between std::string and PyString) or else 
merely accessing the Python wrappers around my own C++ classes. In both 
cases memory ownership remains entirely within the extension module, and 
all interaction occurs through the Python C API, and never indirectly 
through the CRT.

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] Adventures with x64, VS7 and VS8 on Windows

[Kristján Valur Jónsson]

> -Original Message-
> From: "Martin v. Löwis" [mailto:[EMAIL PROTECTED]
> > Just imagine the a school teacher who in good faith wants to
> introduce
> > his pupils to the wonderful programming language of Python, but
> > when he installs it, all kinds of scary looking warnings drive him
> off.
> > Vista is, like it or not, going to be very prevalent.  If we want
> python
> > to be easily accessible to the masses, we mustn't take an elitist
> > attitude or else risk scaring people off.
>
> I'm completely in favor of fixing actual bugs. However, I'm not aware
> of any (related to Vista). That it is not logo compliant is *not*
> a bug. Python hasn't been logo compliant for more than a decade
> now (the "install to Program Files" is not a new requirement, but
> existed since Win95).
>

I'm not saying that it is a bug, but since this is python-dev, I am
discussing it as a desirable "feature".

One feature that is easily addable and will certainly make installing
python on vista nicer, is to add authenticode signing to the install.
Currently the user is faced with a very nasty and off-putting message
about an unidentified program requesting access to his computer.

See http://msdn2.microsoft.com/en-us/library/bb172338.aspx .
I think the PSF should be able to obtain a certificate from MS.

cheers,
Kristján
___
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] Build problems with sqlite on OSX

[Ronald Oussoren]

On 26 May, 2007, at 6:45, Darrin Thompson wrote:


First of all 1000 apologies if this is the wrong list. Please redirect
me if necessary.

I'm attempting to build python 2.5.1 fat binaries on OSX and
statically link to a newer sqlite than what ships with OSX. (3.3.17).

I'm getting "Bus Error" early when I run my app. If I turn on a lot of
malloc debugging options and run under gdb I get this trace:


What happens when you use the binary installer at python.org? This is  
build with a newer version of sqlite as well (because the installer  
supports OSX 10.3).


The script that builds the binary installer is in Mac/BuildScript.

Ronald

smime.p7s
Description: S/MIME cryptographic 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] Adventures with x64, VS7 and VS8 on Windows

[Tony Nelson]

At 1:14 PM + 5/29/07, Kristján Valur Jónsson wrote:
>> -Original Message-
>>
>> Microsoft's command line cannot cope with two pathnames that must be
>> quoted, so if the command path itself must be quoted, then no argument
>> to
>> the command can be quoted.  There are tricky hacks that can work around
>> this mind-boggling stupidity, but life is simpler if Python itself
>> doesn't
>> use up the one quoted pathname.  I don't know if Microsoft has had the
>> good
>> sense to fix this in Vista (which I probably will never use, since an
>> alternative exists), but they didn't in XP.
>
>Do you have any references for this claim?
>In my command line on XP sp2, this works just fine:
>
>C:\Program Files\Microsoft Visual Studio 8\VC>"c:\Program Files\TextPad 
>4\TextPad.exe" "c:\tmp\f a.txt" "c:\tmp\f b.txt"
>
>Both the program, and the two file names are quoted and textpad.exe opens
>them both.

I pounded my head against this issue when working on a .bat file a few
years back, until I read the help for cmd and saw the quote logic (and
switched to VBScript).  It's still there, in "help cmd".  I had once found
references to the same issue for the run command in Microsoft's online help.

Perhaps it is fixed in SP2. If so, just change it and don't worry about
users with earlier versions of Windows.
-- 

TonyN.:'   
  '  
___
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] Build problems with sqlite on OSX

[Darrin Thompson]

On 5/29/07, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
> What happens when you use the binary installer at python.org? This is
> build with a newer version of sqlite as well (because the installer
> supports OSX 10.3).
>

Hmmm. I hadn't thought of checking the sqlite version in there. I did
use the binary installer once but had "other problems" which I'm now
suspecting were my misuse of Qt's pyrcc.

> The script that builds the binary installer is in Mac/BuildScript.
>

Sweet! I'll look into this.

--
Darrin
___
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] whitespace normalization pre-commit hook is giving me grief

[Brett Cannon]

On 5/28/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:


Brett Cannon schrieb:
> Unfortunately the pre-commit hook
> does not specify what line a change was made on so I have no clue where
> it is failing (maybe this should be added?).

It creates a reindent.Reindenter on the new contents, then invokes
.run() on it, and complains if that returns true. If you can come
up with a patch to reindent that makes it report more detailed
errors, please post it, and I'll try to merge it into the hook
script.




The commit worked.  Thanks for fixing this, Martin!  And thanks to Georg for
finding the initial solution.  And thanks to Neal for trying Georg's initial
solution.

-Brett
___
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] Build problems with sqlite on OSX

[Darrin Thompson]

On 5/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> The question for python-dev is "how can I debug that further, and where
> should I submit a patch" :-)
>

I have no problem with that. :-)

> > (gdb) info threads
> > * 1 process 18968 local thread 0x1003  0x900e41d1 in strtol_l ()
> > (gdb) bt
> > #0  0x900e41d1 in strtol_l ()
> > #1  0x900160a5 in atoi ()
> > #2  0x9406fd80 in sqlite3InitCallback ()
>
> Can you figure out what parameter is being passed to atoi() here?
> Go up (u) a few stack frames, list (l) the source, and print (p)
> the variables being passed to atoi().

Well, duh!

#3  0x0395faca in sqlite3_exec (db=0x338d160, zSql=0x338faf0 "SELECT
name, rootpage, sql FROM 'main'.sqlite_master WHERE
tbl_name='sqlite_sequence'", xCallback=0x9406fd00
, pArg=0xbfffde14, pzErrMsg=0x0) at
./src/legacy.c:93
#4  0x0398c741 in sqlite3VdbeExec (p=0x1943e00) at ./src/vdbe.c:4090
#5  0x0395665e in sqlite3Step (p=0x1943e00) at ./src/vdbeapi.c:236

(gdb) l
88azVals = &azCols[nCol];
89for(i=0; iFrom looking at the source code I know that what is being passed to
atoi is supposed to be a root page number.

int sqlite3InitCallback(void *pInit, int argc, char **argv, char **azColName){

Specifically, argv[1] is what goes to atoi, and is documented to be a
root page number. All kinds of possibilities suggest themselves.

> I'm puzzled that it doesn't
> display source code information - so one possible cause is that
> you pick up the wrong sqlite3InitCallback (i.e. the one that
> came with OSX, instead of the one you built yourself).

I'm confident it isn't picking up the wrong lib, based on otool -L:

$ otool -L 
/opt/so/Library/Frameworks/Python.framework/Versions/Current/lib/python2.5/lib-dynload/_sqlite3.so
/opt/so/Library/Frameworks/Python.framework/Versions/Current/lib/python2.5/lib-dynload/_sqlite3.so:
   /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.3)

On Linux I might also poke around in /proc to see what files were
mapped into memory, but I'm not sure how to do that on OSX yet.

--
Darrin
___
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] couple of bug fixes

[Raghuram Devarakonda]

Hi,

I uploaded couple of patches to fix bugs.

1) http://www.python.org/sf/1720897 to fix the bug 668596 (distutils
chops the first character of filenames).

2) http://www.python.org/sf/1713041 to fix the bug 1712742 (pprint
handles depth argument incorrectly).

Both the patches are extremely small (2, 3 lines change) and include
test cases. Can I interest some one to review them?

Thanks,
Raghu.
___
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] New Super PEP

[Dino Viehland]

Just to chime in from the IronPython side (better late than never I suppose):

If we need to get access to the frame which is calling super then we can make 
that happen in IronPython.  It just means that super gets treated like we treat 
eval today and won't work if it's been aliased.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Calvin Spealman
Sent: Sunday, April 29, 2007 12:31 PM
To: Collin Winter
Cc: Python Mailing List
Subject: Re: [Python-Dev] New Super PEP

On 4/29/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 4/29/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> > On 4/29/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > > What if the instance isn't called "self"? PEP 3099 states that "self
> > > will not become implicit"; it's talking about method signatures, but I
> > > think that dictum applies equally well in this case.
> >
> > I don't use the name self. I use whatever the first argument name is,
> > found by this line of python code:
> >
> > instance_name = calling_frame.f_code.co_varnames[0]
>
> So I can't use super with anything but the method's invocant? That
> seems arbitrary.

This will be added to the open issues, but it comes back to the
problem with allow the exact same super implementation both operate in
the super(Class, Object).foo() form and also the super.__call__() form
in the new version.

Any suggestions are welcome for how to solve this.

> > > Also, it's my understanding that not all Python implementations have
> > > an easy analogue to CPython's frames; have you given any thought to
> > > whether and how PyPy, IronPython, Jython, etc, will implement this?
> >
> > I'll bring this up for input from PyPy and IronPython people, but I
> > don't know any Jython people. Are we yet letting the alternative
> > implementations influence so strongly what we do in CPython? I'm not
> > saying "screw them", just pointing out that there is always a way to
> > implement anything, and if its some trouble for them, well, 2.6 or 3.0
> > targetting is far down the road for any of them yet.
>
> It's a smell test: if a given proposal is unduly difficult for
> anything but CPython to implement, it's probably a bad idea. The
> language shouldn't go down the Perl 5 road, where python (the C
> interpreter) becomes the only thing that can implement Python (the
> language).

Understandable. I still haven't contacted anyone about it on in the
PyPy or IronPython worlds, and anyone familiar with Jython who can
comment would be appreciated. Ditto for PyPy and IronPython, even
though I should be able to find some information there myself.

--
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://ironfroggy-code.blogspot.com/
___
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/dinov%40microsoft.com
___
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] Adventures with x64, VS7 and VS8 on Windows

[Martin v. Löwis]

> One feature that is easily addable and will certainly make installing
> python on vista nicer, is to add authenticode signing to the install.

This I question very much. I experimented with authenticode before 2.4,
and found it an unacceptable experience. When the MSI file starts
running, installer needs to verify the signature, for which it needs
to compute a hash of the entire file. For the Python MSI, this takes
many seconds on a slower Pentium 4 machine. During that time, there
is no visual feedback, so users are uncertain whether they have
actually invoked the MSI file at all.

> Currently the user is faced with a very nasty and off-putting message
> about an unidentified program requesting access to his computer.

Certainly. However, telling them that they have to wait just so that
Windows finds out what they know already (that this is the MSI file
from the Python Software Foundation, or from Martin v. Löwis) is
even more nasty.

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

Re: [Python-Dev] Build problems with sqlite on OSX

[Darrin Thompson]

On 5/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> p &sqlite3InitCallback
>

(gdb) p $sqlite3InitCallback
$1 = void

g.

> Try "info shared" in gdb. Not sure whether that works on OSX,
> though.
>

Worked beautifully!

The smoking gun: something is hauling in the system provided sqlite3
in addition to my static one. (Weren't you just saying that?) I'm
going to investigate that further unless you tell me I'm an idiot. I
suspect it's the official Qt binaries from Trolltech doing it
indirectly.

Plus that's the only way I can rationalize some sqlite functions
having source available and some acting like they've been stripped.

--
Darrin
___
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] Build problems with sqlite on OSX

[Martin v. Löwis]

Darrin Thompson schrieb:
> On 5/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> p &sqlite3InitCallback
>>
> 
> (gdb) p $sqlite3InitCallback
> $1 = void

Please try '&' instead of '$'. It's the address of that function
I was after (to then find out whether it is in the address range
of the extension module).

> The smoking gun: something is hauling in the system provided sqlite3
> in addition to my static one. (Weren't you just saying that?) I'm
> going to investigate that further unless you tell me I'm an idiot. I
> suspect it's the official Qt binaries from Trolltech doing it
> indirectly.
> 
> Plus that's the only way I can rationalize some sqlite functions
> having source available and some acting like they've been stripped.

Very likely. I think you will have to read up on "two-level namespaces"
and stuff like that to resolve this.

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