I am attempting to change a directory via its IP address or using it's unc (as I am working in windows). This is due to the external server being mapped to different drives for different users.
Using os.chdir(r'path\\to\remote\directory') does not seem to work and I wonder if there are any alternatives that python doesn't hate i.e. an IP address?
Works fine for me:
Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:59:51) [MSC v.1914 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.chdir(r"\\myserver\myshare")
>>> os.getcwd()
'\\\\myserver\\myshare'
It's hard to tell if the r'path\\to\remote\directory' typo is also in your actual code and how you determined it "does not work".
Related
I'm new to python, and I'm trying to get a basic working understanding of changing the working directory and working with .py files. At the moment, I've changed the directory to where a couple of my .py files are, but when I go to import them, I get a time lag of over a minute for each one. Is that to be expected? Any idea what's going on? Here's what I'm doing:
Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:06:53) [MSC v.1600 64 bit (AMD64)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> import os
>>> os.getcwd()
'C:\\Python33'
>>> os.chdir("C:/Users/MarketResearch")
>>> import EarningsDownload
>>> import RatingsChanges
>>>
Sounds like your module is actually doing work when it is imported. This is (usually) a bad idea. What you should do instead is put your setup code into a function, say setup() or initialize(), and then call it after importing:
import earnings_download
earnings_download.initialize()
I'm trying to register the Firefox browser to run on Windows. According to the documentation for Webbrowser, "If the environment variable BROWSER exists, it is interpreted to override the platform default list of browsers, as a os.pathsep-separated list of browsers to try in order". I tried setting it, but it had no impact.
Z:\>SET BROWSER=C:\Program Files (x86)\Mozilla Firefox\firefox.exe %s
Z:\>python3
Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit (I
tel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> import webbrowser
>>>
>>> webbrowser.open('http://google.com')
True
>>>
webbrowser.get("firefox") doesn't work either
How can I make webbrowser launch Firefox?
You might need to set static envionment viraibles, this you can do in the properties of my computer... Whether or not it will help is for you to figure out (worked over here..).
Another way to do this:
import webbrowser
webbrowser.get("open -a C:\\Program F~\\Mozilla Firefox\\firefox.exe %s")
webbrowser.open('http://google.com')
On 64-bit Debian Linux 6:
Python 2.6.6 (r266:84292, Dec 26 2010, 22:31:48)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.maxint
9223372036854775807
>>> sys.maxunicode
1114111
On 64-bit Windows 7:
Python 2.7.1 (r271:86832, Nov 27 2010, 17:19:03) [MSC v.1500 64 bit (AMD64)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.maxint
2147483647
>>> sys.maxunicode
65535
Both Operating Systems are 64-bit. They have sys.maxunicode, according to wikipedia There are 1,114,112 code points in unicode. Is sys.maxunicode on Windows wrong?
And why do they have different sys.maxint?
I don't know what your question is, but sys.maxunicode is not wrong on Windows.
See the docs:
sys.maxunicode
An integer giving the largest supported code point for a Unicode character. The value of this depends on the configuration option that
specifies whether Unicode characters are stored as UCS-2 or UCS-4.
Python on Windows uses UCS-2, so the largest code point is 65,535 (and the supplementary-plane characters are encoded by 2*16 bit "surrogate pairs").
About sys.maxint, this shows at which point Python 2 switches from "simple integers" (123) to "long integers" (12345678987654321L). Obviously Python for Windows uses 32 bits, and Python for Linux uses 64 bits. Since Python 3, this has become irrelevant because the simple and long integer types have been merged into one. Therefore, sys.maxint is gone from Python 3.
Regarding the difference is sys.maxint, see What is the bit size of long on 64-bit Windows?. Python uses the long type internally to store a small integer on Python 2.x.
I am not getting the reason why my python script is not working though I hv put all the things correctly as my knowledge.The below test I did and it worked fine.But when I import the MySQLdb in my script it gives error as no module name MySQLdb.
**C:\Python26>python
Python 2.6.1 (r261:67517, Dec 4 2008, 16:51:00) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
import MySQLdb
**
Kindly let me know the reason for this error.
And all the development is going on in windows XP, python 2.6, mysql 4.0.3
Earlier 1 hour back I have posted the question but some mistake was there in the question itself..
seems like the path is not set properly.
Getting two different modification time when calculated from different Python versions on Windows XP.
Python2.4
C:\Copy of elisp>c:\python24\python
Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.path.getmtime("auto-complete-emacs-lisp.el")
1251684178
>>> ^Z
Python2.6
C:\Copy of elisp>C:\Python26\python
Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.path.getmtime("auto-complete-emacs-lisp.el")
1251687778.0
>>>
There is a difference of 3600 seconds reported by Python2.6 and Python2.4.
What is the reason of this strange behavior?
It's a bug in Microsoft's implementation of the C standard library. Python 2.4 used to use the stdlib fstat call to get file information, and hence could end up an hour out in locales that use DST.
In Python 2.5 and later, os.stat calls the direct Win32-only API to get file information when running on Windows, resulting in the correct output. See this thread for more.
There is a difference of 3600 seconds ...
This should be the kicker. It's a timezone problem, pure and simple.
Now all you have to do is find out why 2.4 and 2.6 are using different timezone information :-)