Re: I hate you all
On 06.04.2013 23:17, Larry Hudson wrote: [...] What you want and what you think are irrelevant. The Python language (whatever version) is already defined. If you want to use it, you have to accept it and adapt to what it is. Live with it and move on. Complaining about it is a complete waste of time -- it's NOT going to change just because YOU don't like it. Adding an option for fixed size tabs will not change the language (and someone even suggested I patch my own copy, but this discussion is not about me, is about tabs). I guess a discussion like this thread is the price to be paid for relying solely on white space to delimit code blocks, like the python syntax does. And in actual practice, that has been shown to be a Good Thing. Yes, I agree, it is. It just could have been better. Timothy Madden -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 07.04.2013 06:00, Dylan Evans wrote: Then you see my point, unless you are being told what to use by a boss then there are plenty of other languages you can choose from. Python is rigid about it's format, that's just what it is and a lot of people like it but if it's not your thing then some other language will probably suit you better. However, if you are working for a company, or OSS project, you are probably going to have your style dictated whatever language you use [...] I am ok with the people that like python the way it is. But an option from python authors to make tabs work the way they used to would have been nice. Just my opinion, I do see other people here think otherwise... Timothy Madden -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 06.04.2013 08:53, Ian Kelly wrote: On Fri, Apr 5, 2013 at 11:07 PM, Timothy Madden terminato...@gmail.com wrote: [...] So in other words, everybody must be forced to use 8-character tabs because you want to be able to mix tabs and spaces. People say I can use tabs all the way, just set them to the indent I want. Well, I always had my indent independent of the tab size. Which is the way it should be, after all, since one can indent with or without tabs, so indent should not be tied to them. But now I can not; python no longer lets me do that. Honestly, I really don't understand why you *want* to do that. If your indentation is 4 characters, then that would be the natural tab width to use. If you're not going to tie your indent to your tabs, then why even use tabs in the first place? The new rules may look flexible at first sight, but the net effect they have is they push me to use non-default tab size (which is not good), What makes that not good? There is no law anywhere that says tabs are 8 characters. That's just an arbitrary amount that looked appropriate to the people designing the first teletypes. I am aware that 7 bytes per tab character (or 14/28, in UTF-16, UTF-32!) will not justify the time spent debating. The reason I want to use tabs is that I think there is nothing wrong with them. The reason why everybody should use 8-character tabs is so that I and the rest of the world can use `grep` / `findstr` on their code, and still see lines of code properly aligned in the terminal. Or to be able to print fragments of code as plain text only, and get the proper alignment. But most importantly, the reason that tab size should be 8 is so that all of us people in this world can freely exchange formatted text like source code without having to first consider if will it look the same in their editor ? What tab size do they use ? In other words, the solution to different people's definition of tabs is not to drop them, but only to get a common default. Which is already there: 8 columns between every tab stop. What python 3 does is a different attitude, and that is: everyone likes their own indent. Although I personally find it annoying, I am aware that many people use an indent of 2 spaces, some use even 3. Moreover, many C programers still like 8 spaces per indent. So some development environments find it an advantage to use tabs only for indentation, and every programmer is then free to set the tab stop to their liking. Everyone will see the indent they like, with no changes in the byte stream for the file. Why I think this is wrong is a little difficult for me explain. First, I admit this approach toward tabs has some value and is tempting for me, too. But it assumes everything, everywhere can configure tab sizes. Consoles and printers usually do not. Next, even if they can, most people, including all non-technical personal, never bother to change settings. Then this also assumes I change settings to my liking on several computers I use (maybe I work for several clients each with their computers, most people have a work computer and a home computer, maybe also a laptop and a tablet/smart device). Last, this is also not helpful if two sometimes use the same computer from time to time, and do not want to switch users all the time. So this is not a very good approach, and I have the feeling that most python programmers and development environment prefer to use only spaces than to use variable tab sizes. So the right solution remains a proper default setting for the tab size, and then we no longer have to drop tabs from source code files. Thank you, Timothy Madden -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 06.04.2013 08:58, Michael Torrie wrote: [...] As for your problems, perhaps instead of coming on the list with a poorly-thought-out subject line, and desire to simply argue, perhaps you could run your code through a reformatter [...] Hey, I was feeling frustrated ... ! It is how people feel when they no longer have a choice they used to have. But I hear programmers should get used to the feeling: using code that you did not write is bound to trigger that reaction every so often. Timothy Madden -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 06.04.2013 13:17, Joshua Landau wrote: [...] Yours frustratedly, Joshua Landau But seriously, please at least look like you've read other people's posts. It doesn't matter what tabstop you use as long as you don't mix. When the default tab size is 8, than tab size does matter. Because it is too much to use as indent size. If you still want to use tabs, you are now supposed to change tab size from the default. I believe using non-default tab size in a public environment like open-source code is bound to cause formatting problems for someone at some point. If your code depends on tab size then it's categorically wrong. Other people's tab sizes are as valid. I use tabs because of the variation it lets me have - I can switch tab sizes on the fly - and it's faster on dumb editors. So let me do that. But let us assume we were going to standardise on TAB == 8 SPACES. It would *still* be bad to mix tabs and spaces. Hence you'd change Python in exactly 0 ways. So *what do you want from us*? Well all previous (python 2) code is meant to work for a tab size of 8. You may call this categorically wrong, but it has been there a long while, is is still in use, and it sticks to the default. Spaces-only can achieve compatibility between different people settings for formatted text like source code. But so does a common default for the tab size, and with that we do not have to limit ourselves to spaces only. Now I understand python 3 people may already use tabs with a size of 4, as you said. Although I tried to show this is not good practice, (and that not many people do that, really, since most of them prefer to use all-spaces instead), still I do not expect the people to change their settings. What I would expect is some option in python to make tabs work the way they used to. I want a choice for me to preserve my settings, the same way you want to preserve yours. What I want should not be much to ask, since this is how python 2 used to do things. I admit such a '--fixed-tabs' option, that will make tab stops be 8 columns apart, and allow any number of spaces like in python 2, makes the code I write dependent on that option. But the option will run all code written for the new python 3 way, and brings back some compatibility, so it is not that bad. And some people might actually want it. Timothy Madden -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 06.04.2013 17:20, Chris Angelico wrote: On Sun, Apr 7, 2013 at 12:52 AM, Nobody nob...@nowhere.com wrote: Historically, software and hardware which assigns a meaning to a tab character has come in two flavours: 1. Tab stops are every 8 columns; this cannot be changed. 2. Tab stops are configurable, defaulting to every 8 columns. 3. Tab stops are measured in something other than characters. With variable-width fonts, it's illogical to set tab stops in characters. DeScribe Word Processor defined them in centimeters, way back in the early... well, I didn't meet it till the 90s, but I don't know how long it had been around before that. Yes, but systems with variable-width fonts do not make the default for the tab size now. -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 06.04.2013 03:35, Chris Angelico wrote: On Sat, Apr 6, 2013 at 11:22 AM, terminato...@gmail.com wrote: On Saturday, April 6, 2013 1:42:15 AM UTC+3, Ian wrote: [...] The def line has four spaces. The for line then has a hard tab. This is ambiguous. If the hard tab is assumed to have a width of four spaces, then they are at the same indentation level. If it is assumed to have a width of eight spaces, then they are not. [...] The correct tab stop positions have always been at 8 character columns apart. The ambiguity was introduced by editors that do not follow the default value set in hardware like printers or used by consoles and terminal emulators. And now python forces me out of using any tab characters at all. I believe I should still have a choice, python should at lest give an option to set tab size, if the default of 8 is ambiguous now. If you're indenting four spaces per level, then indent four spaces per level. The code you posted would work perfectly if the indentation is four spaces, then eight spaces, then twelve spaces. The problem is that you have a stupid editor that's enforcing tabs instead of certain multiples of spaces - get one that'll keep them all as spaces and you won't have a problem. My editor is not the problem, of course, this is about what I think is right. I think I should be given the option to use tabs as I always have, and at least to use them with the default tab size, as python 2 used to. Or use actual tabs, and set the displayed tab width to whatever you feel like. That works, too. Neither option causes any problems with any sane tools. Well this is the problem, the tab size is not whatever I like, tab stops are 8 character columns apart (default). Changing the tab size from this default is what makes the code incompatible, not the tabs themselves. So the solution is simple: do not change tab size from the default. People say I can use tabs all the way, just set them to the indent I want. Well, I always had my indent independent of the tab size. Which is the way it should be, after all, since one can indent with or without tabs, so indent should not be tied to them. But now I can not; python no longer lets me do that. Tab size should be 8, so now python 3 says: either indent at 8 with tabs, either drop tabs and indent with spaces (just the same as if tabs are not allowed). But that is so wrong. I can indent at 4 (or any value), and still use tabs, as long as the interpreter knows tab stops are 8 columns apart. There is no ambiguity and no way to change the meaning of the code. So as a comparison we have: - the good old rules - python has use the default tab stops of 8 columns - indent is independent of tab stops - the new rules - python is independent of the tab stops - indent is now tied to the tab stop, so users have to : - use non-default tab size (8 is too much), or - drop tabs altogether The new rules may look flexible at first sight, but the net effect they have is they push me to use non-default tab size (which is not good), or drop the tabs, which I could have used before python 3 just fine. Thank you, Timothy Madden -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 06.04.2013 06:53, Ian Kelly wrote: On Fri, Apr 5, 2013 at 6:22 PM, terminato...@gmail.com wrote: The correct tab stop positions have always been at 8 character columns apart. The ambiguity was introduced by editors that do not follow the default value set in hardware like printers or used by consoles and terminal emulators. 8 characters is common, but no more correct than any other, as tab width has never been standardized. You talk of not wanting tab options imposed on you, but consider that treating tabs as 8-character stops imposes that setting on anybody who needs to work with your mixed-indentation code. And now python forces me out of using any tab characters at all. I believe I should still have a choice, python should at lest give an option to set tab size, if the default of 8 is ambiguous now. And then changing that setting could change the meaning of the code, which would be a disaster for code that you want to distribute. 8-character tab stops should be the default. Debating that is I believe another topic, and compatibility with python2 should be enough to make that debate unnecessary. You are right, to change the tab size means to change the meaning of the code, and that would be wrong. Can't argue with that. What I want is an option to use the tabs as I have used them in the past, with the default size. Since ambiguity about the tab size appears to be the cause for new python 3 rules, I though of an option the make that size explicit. I still think users should somehow have a way to use a tab stop of their choice, but how this could be achieved properly is another problem. I guess a discussion like this thread is the price to be paid for relying solely on white space to delimit code blocks, like the python syntax does. Thank you, Timothy Madden -- http://mail.python.org/mailman/listinfo/python-list
How to write a language parser ?
Hello I am trying to write a DBGp client in python, to be used for debugging mostly php scripts. Currently the XDebug module for php allows me to set breakpoints on any line, include blank ones and lines that are not considered executable, resulting in breakpoints that will never be hit, even if program flow control appears to pass through the lines. For that I would like to write a php parser, in order to detect the proper breakpoints line for statements spanning multiple lines. Is there an (open-source) way to do to this in python code ? Most parsers I could see after a search are either too simple for a real programming language, or based on a python module written in C. My debug client is a Vim plugin, and I would like to distribute it as script files only, if that is possible. The generator itself my well be a C module, as I only distribute the generated output. The best parser I could find is PLY, and I would like to know if it is good enough for the job. My attempt at a bison parser (C only) ended in about a hundred conflicts, most of which are difficult to understand, although I admit I do not know much about the subject yet. Are there other parsers you have used for complete languages ? Thank you, Timothy Madden -- http://mail.python.org/mailman/listinfo/python-list
[issue14458] Non-admin installation fails
Timothy Madden terminato...@gmail.com added the comment: The command also worked for me on Windows 7 Professional 64-bit, but pythonw does not start, and I could not check if everything in CLI python.exe works as expected. As you said, something is not right with it, and it also installs just too fast for a real installation. It did get my python installed, though. Thank you for the info, you must have played with it quite a while -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14458 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14458] Non-admin installation fails
Timothy Madden terminato...@gmail.com added the comment: attaching the error message box -- Added file: http://bugs.python.org/file25081/Install-admin-msg.png ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14458 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14458] Non-admin installation fails
New submission from Timothy Madden terminato...@gmail.com: Trying to install the release package (python 3.2.2 x86-64 .msi, 2.7.2 x86-64 .msi) without elevation fails, even if 'Install just for me' is selected in the installer options, and I have write permissions in the selected install folder. Under the same account and conditions, other installers (Mozilla Firefox/Thunderbird, git, Beaver Debugger...) can install successfully. Here the msiexec log file is attached, created with: msiexec /package C:\Users\belladrianc\Downloads\python-3.2.2.amd64.msi /l*v install-3.2.2-x64.log -- components: Installation files: install-3.2.2-x64.log messages: 157183 nosy: toughy priority: normal severity: normal status: open title: Non-admin installation fails type: behavior versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file25080/install-3.2.2-x64.log ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14458 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14458] Non-admin installation fails
Timothy Madden terminato...@gmail.com added the comment: This is happening on Windows Server 2008 R2 Enterprise, Service Pack 1 (64-bit) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14458 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Debugging with gdb: pystack macro for gdb to show python stack trace
Timothy Madden wrote: Hello [...] Can I get the python stack trace working under gdb ? [...] Ok I found some other gdb macros on linked from the wiki page and I had to change them to get the stack trace work. I had to change the symbol PyEval_EvalFrame to PyEval_EvalFrameEx and then I could see the stack trace. The resulting gdb macro was: define pbt set $i = 0 set $j = 0 while $i 1000 select $i if $eip = PyEval_EvalFrameEx if $eip PyEval_EvalCodeEx echo c frame # p $i echo py frame # p $j set $j = $j+1 x/s ((PyStringObject*)f-f_code-co_filename)-ob_sval x/s ((PyStringObject*)f-f_code-co_name)-ob_sval echo line # p f-f_lineno end end set $i = $i+1 end end document pbt show python backtrace end Thank you, Timothy Madden -- http://mail.python.org/mailman/listinfo/python-list
Debugging with gdb: pystack macro for gdb to show python stack trace
Hello I have an application with several threads that sometimes just freezes. I installed the debug symbols for python interpreter, and the gdb macros, as instructed on the wiki http://wiki.python.org/moin/DebuggingWithGdb so I can debug with gdb. gdb loads many files with python debugging simbols, and it is loading the macros file ~/.gdbinit, but still the macros for working with python are not working. The pystack command just freezes the debugger until I press ^C, and other macros complain about undefined symbols. I would like to see the python stack trace so I know where my application freezes. All I could see from the gdb native stack trace (with bt) was that my 3 threads were waiting to acquire a lock, but I could not figure out where and my program logic should not allow this to happen. Can I get the python stack trace working under gdb ? Synaptic Package Manager on my Ubuntu netbook shows packages python2.6 (2.6.2-0ubuntu1) python2.6-dbg (2.6.2-0ubuntu1) as installed, and I extracted the Misc/gdbinit file from Python-2.6.2.tar.bz2 source archive from python.org. I have gdb 6.8-debian. So I suppose everything should be right ... Thank you, Timothy Madden -- http://mail.python.org/mailman/listinfo/python-list
Writing a thread-safe class
Hello I would like to write a class with methods that can be accessed by many threads at the same time. For this I have a lock attribute in my class obtained with threading.Lock(), in the constructor, and every method begins by acquiring the lock and ends by releasing it My problem is that the lock is still an attribute of the class, and the very expression self.lock in the statement self.lock.acquire() is performed before locking, thus not being thread-safe. If I am correct self is a dictionary of object attributes, and if another thread has the lock and creates a new attribute, or deletes one, in the same time with my lookup for self.lock, than the lookup is compromised. How do people create thread-safe classes in python ? Thank you, Timothy Madden -- http://mail.python.org/mailman/listinfo/python-list
Re: How to refer to data files without hardcoding paths?
Matthew Wilson wrote: When a python package includes data files like templates or images, what is the orthodox way of referring to these in code? I'm working on an application installable through the Python package index. Most of the app is just python code, but I use a few jinja2 templates. Today I realized that I'm hardcoding paths in my app. They are relative paths based on os.getcwd(), but at some point, I'll be running scripts that use this code, these open(...) calls will fail. I found several posts that talk about using __file__ and then walking to nearby directories. I also came across pkg_resources, and that seems to work, but I don't think I understand it all yet. Matt sys.path[0] should give you the path to your script. By reading the documentation I would say it would give the path to the first script passed to the interpreter at launch, but after using it I find it also gives the current script path inside an imported file. So I use it to group the script files in my application into subdirectories, and import them as necessary from there. My app works regardless of the current working directory, and can import scripts and load icons from its various subdirectories. Still I would like to know why it works in imported scripts, since the doc page says sys.path[0] is the path to the script that caused the interpreter to launch. What would that mean ? Timothy Madden -- http://mail.python.org/mailman/listinfo/python-list
Re: How to access ODBC databases ?
Martin P. Hellwig wrote: Timothy Madden wrote: cut [...] It has been a couple of years, but I remember vaguely that back in the days of PossgreSQL 6, if you want ODBC support you needed to compile PG a bit different then normal, I am not really sure what options those where and if this still applies, I decided to not use ODBC because it resulted in an undesirable effect somewhere else. Though I am not sure if that is still the case. Sorry to hear that. I think ODBC is an important step towards DBMS-independent applications, or even database applications portable over DBMSs. Yes, I know, everyone says such applications are so far from reality that they are not worth any effort trying. I still consider that ODBC is at least a step, and I am only sorry PostgreSQL has a poor ODBC driver (no large objects natively). Python also has a unified independent database interface with the DB API, and so does php and maybe other products. Thank you for your help, Timothy Madden -- http://mail.python.org/mailman/listinfo/python-list
Is #!/usr/bin/env python the better shebang line ?
Hello Sorry if this has been discussed before, my search did not find it. My questions is if I should use #!/usr/bin/env python as the shebang line in a portable and open python script and if it does help with portability and usage. First, can one not find /usr/bin/python in any standard system, at least as much as /usr/bin/env can be found ? Then, supposing /usr/bin/env is better than /usr/bin/python and I use it, is it not the case that many editors and code analysing programs, that want to know the script language for syntax highlighting, code completion, tags and source code browsing, etc, will loose their functionality because of this shebang line ? Is this not a good general reason to use the old one ? Now I know env is POSIX standard utility, and python is not, and maybe that could be reason enough, but are there any other issues involved with using /usr/bin/env ? Thank you Timothy Madden -- http://mail.python.org/mailman/listinfo/python-list
How to debug a forked process with pdb ?
Hello
I am trying to write a daemon and I call os.fork() twice to detach from
the terminal and other staff.
Problem is after the second fork() the child immediately gives an
exception and although I get a traceback displayed the process should
terminate, the child proces is still live, and its parent is waiting in
a loop for the child to either exit or send SIGUSR1 to it to indicate
the daemon has started up and is in the running state.
The problem is the daemon script has terminated with an uncaught
exception and a traceback displayed, but the process is still hanging
there. Do you know why would it not exit ?
Trying to kill the daemon process, even as root, fails silently. Do you
know why that would happen ?
I would like to debug the scrip with
python -m pdb pikantBlue.py
but after the first fork() call the debugger prompt is unusuable.
Probably the same prompt is shared by two instances of pdb, that have
forked once with my script. Do you know how can I debug a script that
forks ?
You have my script attached if you want to look it over. The child
failes and somehow freezes at the import line at the end of the file,
and its parent is livelocked in the while loop.
Thank you,
Timothy Madden
---
#!/usr/bin/env python
import sys, os, signal, time
from pikantBlueServer import PIDFile as PIDFile, pid_file as pid_file
serverRunning = False
def serverRunningSignal(usrSignal, stackFrame):
global serverRunning
if (usrSignal == signal.SIGUSR1):
serverRunning = True
wait_message = False
def waitAlarm(sigAlarm, stackFrame):
global wait_message
sys.stdout.write('Starting daemon ... ')
wait_message = True
def daemonize(loop, fileLst):
exitCode = False
sys.stdin.flush()
sys.stdout.flush()
sys.stderr.flush()
pid = os.fork()
if pid 0:
# the main process
#
# returns with the exit code of the proxy child
print 'Proxy proces' , pid
exitCode = (os.waitpid(pid,0) == 0)
else:
# the proxy child
#
# sets cwd, umask and sid, forks the server
# waits for either it's termination or the ready signal
os.setsid()
signal.signal(signal.SIGUSR1, serverRunningSignal)
sys.stdin.flush()
sys.stdout.flush()
sys.stderr.flush()
pid = os.fork()
if pid 0:
#proxy process waits for termination of the child or the
#ready signal
print 'Daemon process', pid
signal.signal(signal.SIGALRM, waitAlarm)
signal.alarm(1)
waitPid = True
global serverRunning
if not serverRunning:
try:
os.kill(pid, 0)
except OSError, e:
if hasattr(e, 'errno') and e.errno == errno.ESRCH:
waitPid = False
else:
raise
while waitPid and not serverRunning:
time.sleep(10)
if not serverRunning:
try:
sys.stdout.write('Checking child process ' + str(pid) +
' ... ')
os.kill(pid, 0)
print 'live.'
except OSError, e:
if hasattr(e, 'errno') and e.errno == errno.ESRCH:
waitPid = False
print 'dead'
else:
raise
signal.alarm(0)
global wait_message
if waitPid and wait_message:
print 'done'
exitCode = serverRunning
else:
# the server process
#
signal.signal(signal.SIGUSR1, signal.SIG_DFL)
os.chdir('/')
os.umask(0)
try:
import pikantBlueSever
exitCode = pikantBlueServer.start(loop, fileLst)
except:
exitCode = False
return exitCode
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is #!/usr/bin/env python the better shebang line ?
Ned Deily wrote: In article 4aa3bfdf$0$282$14726...@news.sunsite.dk, Timothy Madden terminato...@gmail.com wrote: My questions is if I should use #!/usr/bin/env python as the shebang line in a portable and open python script and if it does help with portability and usage. This question came up recently on stackoverflow (alas, will result in urloverflow): http://stackoverflow.com/questions/1352922/why-is-usr-bin-env-python-supp osedly-more-correct-than-just-usr-bin-pyth/1352938#1352938 Ok, thank you. There is quite a flame since May 2008 archived on mail.python.org about this issue. #!/usr/bin/env python is clearly the choice for my scripts. It helps a lot with portability, and the arguments against it are based on the idea that /usr/bin/python is somehow better than /opt/python and that /opt/python is still in front of /usr/bin/python in path. Such an argument I do not find compelling. The thing is that people writing large applications for many systems need flexibility first. Timothy Madden -- http://mail.python.org/mailman/listinfo/python-list
Re: How to access ODBC databases ?
Martin P. Hellwig wrote:
Timothy Madden wrote:
Martin P. Hellwig wrote:
Timothy Madden wrote:
cut
conn = pyodbc.connect('DRIVER={PostgreSQL
Unicode};Servername=127.0.0.1;UID=pikantBlue;Database=pikantBlue')
Traceback (most recent call last):
File stdin, line 1, in module
pyodbc.Error: ('0', '[0] [nxDC (202) (SQLDriverConnectW)')
Not sure (i.e. wild guess) but that line makes me think it has
something to do with the encoding, is it possible to try a different
driver?
Thank you.
Slackware also comes with mysql, I guess I could try to install and
register a driver for it in my unixODBC installation.
What about the encoding ? What should I be looking for in this case ?
Indeed when I try
createdb --encoding=UTF-8 pikantBlue
I get the message that the server's /LC_TYPE settings require encoding
to be LATIN1/. What should I do about it ? Should I have been more
careful about the configure options when compiling postgresql ? I also
tried pyodbc on Ubuntu with the database installed with apt-get and I
still get the same problem.
Thank you
Timothy Madden
According to this:
http://psqlodbc.projects.postgresql.org/faq.html#2.5
You could try the 'PostgreSQL ANSI' driver.
Thank you.
The precompiled psqlodbca.so driver from apt-get worked on one of the
Ubuntu machines that I tried.
I would still like o use the Unicode driver if possible. Do you know
what the problem could be ? Or where ? pyodbc/unixODBC/psqlodbcw.so ?
Thank you,
Timothy Madden
--
http://mail.python.org/mailman/listinfo/python-list
How to access ODBC databases ?
Hello
I would like to use a database through ODCB in my python application. I
have Slackware Linux, but I would not mind a portable solution, since
python runs on both Unixes and Windows.
I would like a free/open-source solution and the python module for ODBC
access that I have found is *pyodbc*, but the problem is it fails to
connect to my database with an error like:
conn = pyodbc.connect('DRIVER={PostgreSQL
Unicode};Servername=127.0.0.1;UID=pikantBlue;Database=pikantBlue')
Traceback (most recent call last):
File stdin, line 1, in module
pyodbc.Error: ('0', '[0] [nxDC (202) (SQLDriverConnectW)')
Do you know what the problem is ? My database is working and I can
connect with *psql -U pikantBlue*, and also my ODBC installation is
working and I can connect with *isql pikantBlue*.
From python I can also connect with the *pyodb* module, which is
another module for ODBC access, but pyodb does not have query parameters
and all
the functions in the DB api, it is only meant the be a simple way to
acccess ODBC.
Do you know why my *pyodbc* module would not connect, when others will ?
Do you know other modules to use ODBC in python ?
Thank you
Timothy Madden
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to access ODBC databases ?
Martin P. Hellwig wrote:
Timothy Madden wrote:
cut
conn = pyodbc.connect('DRIVER={PostgreSQL
Unicode};Servername=127.0.0.1;UID=pikantBlue;Database=pikantBlue')
Traceback (most recent call last):
File stdin, line 1, in module
pyodbc.Error: ('0', '[0] [nxDC (202) (SQLDriverConnectW)')
Not sure (i.e. wild guess) but that line makes me think it has something
to do with the encoding, is it possible to try a different driver?
Thank you.
Slackware also comes with mysql, I guess I could try to install and
register a driver for it in my unixODBC installation.
What about the encoding ? What should I be looking for in this case ?
Indeed when I try
createdb --encoding=UTF-8 pikantBlue
I get the message that the server's /LC_TYPE settings require encoding
to be LATIN1/. What should I do about it ? Should I have been more
careful about the configure options when compiling postgresql ? I also
tried pyodbc on Ubuntu with the database installed with apt-get and I
still get the same problem.
Thank you
Timothy Madden
--
http://mail.python.org/mailman/listinfo/python-list
Re: python3 module for dbus ?
Aahz wrote: In article 4a1281ef$0$90271$14726...@news.sunsite.dk, Timothy Madden terminato...@gmail.com wrote: [...] Do you know if I can get dbus bindings for python3 and glib bindings for python3 ? Or could I use them otherwise (like without the modules) ? Sorry, no answers to your questions off-hand, but what's wrong with using 2.x? It is now old and will be replaced by 3.0 And I am starting a new project. I think it would be appropriate to start it with the new version of python. Timothy Madden -- http://mail.python.org/mailman/listinfo/python-list
python3 module for dbus ?
Hello Sorry if this is not the right newsgroup for python modules, I found no other appropriate one. I would like to start a project in python and I think it would be good to start with python3.0, but I need tu use glib, dbus, wxWidgets and postgresql. Do you know if I can get dbus bindings for python3 and glib bindings for python3 ? Or could I use them otherwise (like without the modules) ? Thank you Timothy Madden -- http://mail.python.org/mailman/listinfo/python-list
