Wow, such a quick reply
dot(s) in directory path name:
Robin Dunn:
That has not been true since the introduction of the FAT32 (or vfat)
filesystem. Prior to that the 8.3 filename was hard coded into the file
system data structures themselves. Now the names can be up to 255
characters and multiple dots are allowed...
Chis Mellon:
...Tools that do this are broken. There's plenty of tools that assume
you can't have spaces in filenames also, those ...
However, can you point out any tools that incorrectly deal with
directories with dots in them? I'd be interested, if only so that I
can avoid them....
It is true, that I still have antedeluvian tools software dating from the win95
times. Especially, my cd recording application.
(It seems my machine is showing its age...)
Correction: I just checked the manual, you're misinterperting it. The
fact that the extension seperator is "." does not mean that dots are
only allowed as extension seperators. Python deals fine with
directories that have dots in the name.
You are right, mea culpa.
So, the problem is solved.
Robind Dunn:
- Small bug(?) in wxversion.py. The ..\site-package\wx-** is
registrated twice in sys.path. The duplication is due to *.pth
file and the internal wx dir searching, when updating the sys.path
or something like this. Easy to fix.
Hmm... I thought I was removing any existing paths found. I guess I
forgot to do that.
I did not dive seriously into the wxversion.py. I noticed this
when testing my my psi shell. I also have a small wxPy application,
that displays only the sys.path in a TextCtrl.
(I also always forget to check a path existence in a "sys.path" before
appending it.)
With:
va = '2.5.2.8'
vb = '2.5'
import sys
import wxversion
wxversion.require(vb)
import wx
I get this:
wxPython: 2.5.3.0p.20041015
···
-------
C:\PYTHON23\lib\site-packages\wx-2.5.3-msw-ansi <<<<<<<<<<
C:\jm\jmpy\wxversiontestapp
C:\PYTHON23\PYTHON23.zip
C:\jm\jmpy\wxversiontestapp
C:\PYTHON23\DLLs
C:\PYTHON23\lib
C:\PYTHON23\lib\plat-win
C:\PYTHON23\lib\lib-tk
C:\PYTHON23
C:\jm\jmpy\jmlib
C:\PYTHON23\lib\site-packages
C:\PYTHON23\lib\site-packages\wx-2.5.3-msw-ansi <<<<<<<<<<<
and with:
va = '2.5.2.8'
vb = '2.5'
import sys
#~ import wxversion
#~ wxversion.require(vb)
import wx
I get:
wxPython: 2.5.3.0p.20041015
-------
C:\jm\jmpy\wxversiontestapp
C:\PYTHON23\PYTHON23.zip
C:\jm\jmpy\wxversiontestapp
C:\PYTHON23\DLLs
C:\PYTHON23\lib
C:\PYTHON23\lib\plat-win
C:\PYTHON23\lib\lib-tk
C:\PYTHON23
C:\jm\jmpy\jmlib
C:\PYTHON23\lib\site-packages
C:\PYTHON23\lib\site-packages\wx-2.5.3-msw-ansi
Robin Dunn:
- I have a serious concern with py2exe. py2exe does not like
wxversion.py. Py2exe is working, it is building the exe. Later,
the executable is not recognizing the "wx path". I do not think,
<> that this is a py2exe bug, but more an unpleasant side-effect.
I wondered about this. Does it work if you don't use wxversion but let
it naturally find the default wxPython specified in the wx.pth?
If I take my above test application
with:
va = '2.5.2.8'
vb = '2.5'
import sys
#~ import wxversion
#~ wxversion.require(vb)
import wx
The executable gives:
wxPython: 2.5.3.0p.20041015
-------
C:\JM\JMPY\WXVERSIONTESTAPP\DIST\library.zip
That's ok.
But with:
va = '2.5.2.8'
vb = '2.5'
import sys
import wxversion
wxversion.require(vb)
import wx
The exe is not working. It create a log file with:
Traceback (most recent call last):
File "testversion.py", line 12, in ?
File "wxversion.pyc", line 77, in require
AssertionError: Required version of wxPython not found
A last question, I forget in my previous post.
Is it not time to drop the wxPython subdir? All the
demo seems to be wx compliant.
jmf, Switzerland