ctypes argument by reference

[gaetan]

Hi
I try to write a python backend for pamcan-g2, for that I should write a 
callback for *trans_cb_conv

In python I've write :
trans_cb_event = CFUNCTYPE(ctypes.c_char_p,ctypes.c_void_p,POINTER(ctypes.c_int)
...
def fpm_trans_conv(event,pkg,response):
foo...
response=1
and for call the callback
if trans_init(pm_trans,flags, trans_cb_event(fpm_progress_event), 
trans_cb_conv(fpm_trans_conv), None) == -1 :
foo...

Into libpacman response is a C int pointer :
...
QUESTION(trans, PM_TRANS_CONV_LOCAL_UPTODATE, local, NULL, NULL, &resp);
...

but resp=0 howto pass response by reference instead by value ?

If you would more informations/code :
the .h is here : 
http://git.frugalware.org/gitweb/gitweb.cgi?p=pacman-g2.git;a=blob_plain;f=lib/libpacman/pacman.h;hb=HEAD
the python code here : 
http://git.frugalware.org/gitweb/gitweb.cgi?p=frugal-tweak.git;a=blob_plain;f=py-pacman/py-pacman.py;hb=4abed4ee445f009387a3a51957e231c010c123bb

trans_cb_event line 315
fpm_trans_conv line 676
pacman_trans_init callback 708
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Multiprocessing bug, is information ever omitted from a traceback?

[John Ladasky]

I hope that the interested parties who offered me help will remember
this thread title.  It has been a few weeks.

After fussing around with an alternate installation of Python 2.7.2 on
top of Ubuntu Linux 10.04, I decided it would be easier to upgrade to
Ubuntu 11.10, for which Python 2.7.2 is the default Python version.  I
have reproduced my Python 2.6.6 bug in Python 2.7.2, as you will see.

On Dec 9, 3:14 pm, I wrote:

> All lines of code referenced in the traceback are in the standard
> library code:
>
> Exception in thread Thread-1:
> Traceback (most recent call last):
>   File "/usr/lib/python2.6/threading.py", line 532, in
> __bootstrap_inner
>     self.run()
>   File "/usr/lib/python2.6/threading.py", line 484, in run
>     self.__target(*self.__args, **self.__kwargs)
>   File "/usr/lib/python2.6/multiprocessing/pool.py", line 284, in
> _handle_tasks
>     put(task)
> TypeError: expected string or Unicode object, NoneType found
>
> Fortunately, I have a working version of my code.  I was trying to add
> new features, and only my new code is causing trouble.  This has
> allowed me to examine the contexts of task when everything works.
>
> Task is not a string when the program works.  Task is not None when
> the program doesn't work.  In fact, task is a deeply-nested tuple.  NO
> PART of this tuple ever contains any strings, as far as I can tell.
> More details in my original thread.

Here's the traceback that I obtained tonight.  It's essentially the
same, except for the line numbers in the library code and the thread
number which yielded the exception:

| Exception in thread Thread-2:
| Traceback (most recent call last):
|   File "/usr/lib/python2.7/threading.py", line 552, in
__bootstrap_inner
| self.run()
|   File "/usr/lib/python2.7/threading.py", line 505, in run
| self.__target(*self.__args, **self.__kwargs)
|   File "/usr/lib/python2.7/multiprocessing/pool.py", line 315, in
_handle_tasks
| put(task)
| TypeError: expected string or Unicode object, NoneType found


I still have more work to do, I know.  I will try to pare down my
fairly-complex code to a minimal example.  Check back again in a few
days?  Weeks?  Thanks!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Slices when extending python with C++

[Robert Kern]

On 12/27/11 11:02 PM, roze...@volny.cz wrote:

Hallo,
I have kind of special question when extening python with C++
implemented modules.

I try to implement a class, behaving also like an array. And I need
to implement slice-getters. I implemented PySequenceMethods.sq_slice
to get "simple" slices like:

myobj[x:y]

It works perfectly, without problems. But now I have a problem when
need to access the array with "special" slices, like:

myobj[x:y:step]
myobj[::-1]  # to revert the array

I would like to ask which method must be implemented to get this
"special" slice getters. The "simple" slice
PySequenceMethods.sq_slice getter accepts only two indexes - from,
to, but not a step (which would solve the issue).


The sq_slice slot is deprecated, just like the __getslice__() method on the 
Python side. Instead, implement sq_item to accept a slice object in addition to 
integer indices.


http://docs.python.org/c-api/slice.html

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

--
http://mail.python.org/mailman/listinfo/python-list

globals function

[Emeka]

Hello All,

What is the downside of using globals function

Regards,
Janus

-- 
*Satajanus  Nig. Ltd


*
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pythonification of the asterisk-based collection packing/unpacking syntax

[Eelco]

On Dec 27, 11:57 pm, Steven D'Aprano  wrote:
> On Mon, 26 Dec 2011 13:41:34 -0800, Eelco wrote:
> > On Dec 25, 6:05 pm, Steven D'Aprano  > +comp.lang.pyt...@pearwood.info> wrote:
> >> On Sun, 25 Dec 2011 07:38:17 -0800, Eelco wrote:
>
> [...]
>
> >> > How is 'head, *tail = sequence' or semantically entirely
> >> > equivalently, 'head, tail::list = sequence' any different then? Of
> >> > course after interpretation/compilation, what it boils down to is
> >> > that we are constructing a list and binding it to the identifier
> >> > tail, but that is not how it is formulated in python as a language
>
> >> I'm afraid it is.
>
> >> Here's the definition of assignment in Python 3:
> >>http://docs.python.org/py3k/reference/simple_stmts.html#assignment-
> >> statements
>
> > Que?
>
> You have claimed that "constructing a list and binding it to the
> identifier" is not how iterator unpacking is formulated in Python the
> language. But that is wrong. That *is* how iterator unpacking is
> formulated in Python the language. The reference manual goes into detail
> on how assignment is defined in Python. You should read it.
>
> > 'head, *tail = sequence'
>
> > Is how one currently unpacks a head and tail in idiomatic python
>
> > This is semantically equivalent to
>
> > 'head = sequence[0]'
> > 'tail = list(sequence[1:])'
>
> There's a reason this feature is called *iterable* unpacking: it operates
> on any iterable object, not just indexable sequences.
>
> 'head, *tail = sequence' is not just semantically equivalent to, but
> *actually is* implemented as something very close to:
>
> temp = iter(sequence)
> head = next(temp)
> tail = list(temp)
> del temp
>
> Extended iterable unpacking, as in 'head, *middle, tail = sequence' is a
> little more complex, but otherwise the same: it operates using the
> iterator protocol, not indexing. I recommend you read the PEP, if you
> haven't already done so.
>
> http://www.python.org/dev/peps/pep-3132/
>
> > But these forms are linguistically different, in too many different ways
> > to mention.
>
> How about mentioning even one way? Because I have no idea what
> differences you are referring to, or why you think they are important.

The one spans two lines; the other one. Need I go on?

> >> > We dont have
> >> > something of the form 'tail = list_tail(sequence)'.
>
> >> I'm afraid we do. See the definition of assignment again.
>
> > Que?
>
> Again, you make a claim about Python which is contradicted by the
> documented behaviour of the language. You claim that we DON'T have
> something of the form 'tail = list_tail(sequence)', but that is *exactly*
> what we DO have: extracting the tail from an iterator.
>
> Obviously there is no built-in function "list_tail" but we get the same
> effect by just using list() on an iterator after advancing past the first
> item.
>
> > My claim is that the two semantically identical formulations above do
> > not have isomorphic linguistic form. As far as I can make sense of your
> > words, you seem to be disputing this claim, but its a claim as much
> > worth debating as that the sun rises in the east.
>
> "Isomorphic linguistic form"? Are you referring to the idea from
> linguistics that there are analogies between the structure of phonic and
> semantic units? E.g. that the structures (phoneme, syllable, word) and
> (sememe, onomateme, sentence) are analogous.
>
> I don't see why this is relevant, or which units you are referring to --
> the human-language description of what Python does, high-level Python
> language features, Python byte-code, or machine code. Not that it
> matters, but it is unlikely that any of those are isomorphic in the
> linguistic sense, and I am not making any general claim that they are.
>
> If not, I have no idea what you are getting at, except possibly trying to
> hide behind obfuscation.

I wasnt too worried about obfuscation, since I think there is little
left to lose on that front. Let me make a last-ditch effort to explain
though:

When python reads your code, it parses it into a symbolic graph
representation. The two snippets under consideration do not parse into
the same graph, in the same way that insignificant whitespace or
arbitrary identifier names do, for instance. Hence, not linguistically
isomorphic.

The very function of a programming language is to transform this
representation of the code into semantically identical but different
code; (machine code, eventually). You fail to grok the difference
between semantic equivalence and linguistic equivalence. Yes, there
can be a semantic equivalence between iterable unpacking and a syntax
of the form tail_list(sequence). And python does indeed probably apply
a transformation of this kind under the hood (though we couldnt care
less what it does exactly). AND IT PERFORMS THAT TRANSFORMATION USING
THE TYPE CONSTRAINT GIVEN.

Another example: the C code 'float x = 3', how would you interpret
that? Is it 'not a type constraint on x', because eventually your C
compiler t

Re: Pythonification of the asterisk-based collection packing/unpacking syntax

[Eelco]

On Dec 28, 2:11 am, Rick Johnson  wrote:
> On Dec 27, 5:10 pm, Steven D'Aprano 
> +comp.lang.pyt...@pearwood.info> wrote:
> > On Sun, 25 Dec 2011 07:47:20 -0800, Eelco wrote:
> > Your original use-case, where you want to change the type of tail from a
> > list to something else, is simply solved by one extra line of code:
>
> > head, *tail = sequence
> > tail = tuple(tail)
>
> i wonder if we could make this proposal a bit more "Pythonic"? Hmm...
>
> head, tuple(tail) = sequence
>
> ...YEP!

That has been considered; it was my first thought too, but this
requires one to break the symmetry between collection packing and
unpacking.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Get Class properties

[Emeka]

Hello All,


I have seen what I am looking for.. __dict__.

Thanks!

Regards,
Janus

On Wed, Dec 28, 2011 at 1:05 PM, Emeka  wrote:

>
> Hello All,
>
> Say I have a class like below
>
>   class Town:
>  state = StateClass()
>  cities = CityClass()
>
>
> Is there way to introspect such that one can list the properties keys and
> their values in such a way that it would look like playing around
> dictionary ?
>
> Regards,
> Janus
> --
> *Satajanus  Nig. Ltd
>
>
> *
>



-- 
*Satajanus  Nig. Ltd


*
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pythonification of the asterisk-based collection packing/unpacking syntax

[Eelco]

On Dec 28, 8:08 am, Chris Angelico  wrote:
> On Wed, Dec 28, 2011 at 5:25 PM, Steven D'Aprano
>
>
>
>
>
>
>
>
>
>  wrote:
> > On Wed, 28 Dec 2011 15:06:37 +1100, Chris Angelico wrote:
>
> >> ... suppose you have a huge
> >> set/frozenset using tuples as the keys, and one of your operations is to
> >> shorten all keys by removing their first elements. Current Python
> >> roughly doubles the cost of this operation, since you can't choose what
> >> type the tail is made into.
>
> > The First Rule of Program Optimization:
> > - Don't do it.
>
> > The Second Rule of Program Optimization (for experts only):
> > - Don't do it yet.
>
> > Building syntax to optimize imagined problems is rarely a good idea. The
> > difference between 2 seconds processing your huge set and 4 seconds
> > processing it is unlikely to be significant unless you have dozens of
> > such huge sets and less than a minute to process them all.
>
> > And your idea of "huge" is probably not that big... it makes me laugh
> > when people ask how to optimize code "because my actual data has HUNDREDS
> > of items!". Whoop-de-doo. Come back when you have a hundred million
> > items, then I'll take your question seriously.
>
> > (All references to "you" and "your" are generic, and not aimed at Chris
> > personally. Stupid English language.)
>
> And what you're seeing there is the _best possible_ situation I could
> think of, the strongest possible justification for new syntax.
> Granted, that may say more about me and my imagination than about the
> problem, but the challenge is open: Come up with something that
> actually needs this.
>
> ChrisA

I personally feel any performance benefits are but a plus; they are
not the motivating factor for this idea. I simply like the added
verbosity and explicitness, thats the bottom line.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pythonification of the asterisk-based collection packing/unpacking syntax

[Eelco]

On Dec 28, 12:07 am, Steven D'Aprano  wrote:
> On Mon, 26 Dec 2011 13:51:50 -0800, Eelco wrote:
>
> [...]
>
> >> If your point is that parens are used more often than
> >> packing/unpacking, that's almost certainly true, since function calls
> >> (including method invocations) are so prevalent in pretty much any
> >> code. But what does that prove?
>
> > That proves the original point of contention: that the below* is
> > suboptimal language design,
>
> Well duh.

This is where the referee should interrupt you for snipping someones
citation right before a 'but'

> I was mocking the idea that the meaning of * is context-dependent is a
> bad thing by pointing out that we accept context-dependent meaning for
> round brackets () without any difficulties. Of course it is "suboptimal
> language design" -- it couldn't fail to be. Context-dependency is not
> necessarily a bad thing.

You know, so you dont end up simply restating my point while trying to
make it seem like you disagree.

> > not because terseness always trumps
> > verbosity, but because commonly-used constructs (such as parenthesis or
> > round brackets or whatever you wish to call them)
>
> Parentheses are not a construct. They are symbols (punctuation marks)
> which are applied to at least three different constructs: grouping,
> function calls, class inheritance lists.

Parenthesis encompass a class of constructs. Happy now?

> > are more deserving of
> > the limited space in both the ascii table and your reflexive memory,
> > than uncommonly used ones.
>
> Right. And since sequence packing and unpacking is a common idiom, it
> deserves to be given punctuation. That's my opinion.

Its a valid opinion. But if we are going to be quantitative about
terms such as 'common', you know that there will be at least an order
of magnitude difference between these constructs in commonality, if
not two. Thats what makes your example a poor one. If you could
verbosify a construct of the same commonality and arrive at equally
absurd code, you would have a point.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python education survey

[Eelco]

On Dec 28, 2:56 am, Rick Johnson  wrote:
> On Dec 27, 3:44 pm, Eelco  wrote:
>
> > Despite the fact that you mis-attributed that quote to me, im going to
> > be a little bit offended in the name of its actual author anyway.
> > Thats a lot of words to waste on your linguistic preferences.
> > Personally, I reserve the right to botch my non-native languages as
> > much as I please.
>
> I hope you're just joking a bit because i have little respect for
> those who refuse to better themselves. If you are learning English as
> a second language then you have a legitimacy excuse, but at some point
> that excuse just becomes a lie. In any case, i apologize for mis-
> quoting you.

Yes, I was joking a bit; I learned my english primarily on programming
boards, and im proud to say it rivals that of a majority of native
speakers (low bar to beat, true). Furthermore, you are free to direct
criticism at my writing or that of anyone else, but I must say I dont
much care to hear it. A language is learned by using it, in reading,
writing or speech; not by grammar nazis, or style nazis for that
matter. Im here to discuss issues related to python, and anyone who
manages to make himself understood is welcome to do so, as far as I am
concerned. Im much more worried whether they have something
interesting to contribute to the actual discussion. Not getting stuck
picking nits, fighting personal feuds or getting dragged into the
swamp by trolls; those are the real challenges, in my opinion.

If you are insistent on bettering yourself; there is half a dozen
other languages we could continue the conversation in. Your marginal
gain per sentence read and written might be much larger there than in
english.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Slices when extending python with C++

[rozelak]

Dear Robert,

thank you very much for your answer. I understand what you mean and
I have looked at slice object and C-api methods it provides. It
should be easy to implement it.

The only question is how exactly yo implement the general getter,
since sq_item you mention (assume you mean 
PySequenceMethods.sq_item) has the following signature:

PyObject * (* ssizeargfunc)(PyObject *, Py_ssize_t)

accepting Py_ssize_t as the index, not a PyObject * which would hold
the slice.

So, how exactly to implement the getter? As a general method named
__getitem__ registered in PyMethodDef? Or in another way?

Thank you very much again. Regards,
Dan



- PŮVODNÍ ZPRÁVA -
Od: "Robert Kern" 
Komu: python-list@python.org
Předmět: Re: Slices when extending python with C++
Datum: 28.12.2011 - 10:24:42

> On 12/27/11 11:02 PM, roze...@volny.cz wrote:
> > Hallo,
> > I have kind of special question when extening
> > python with C++
> > > implemented modules.
> >
> > I try to implement a class, behaving also like
> > an array. And I need
> > > to implement slice-getters. I implemented
> > PySequenceMethods.sq_slice
> > > to get "simple" slices like:
> >
> > myobj[x:y]
> >
> > It works perfectly, without problems. But now I
> > have a problem when
> > > need to access the array with "special" slices,
> > like:
> > >
> > myobj[x:y:step]
> > myobj[::-1]  # to revert the array
> >
> > I would like to ask which method must be
> > implemented to get this
> > > "special" slice getters. The "simple" slice
> > PySequenceMethods.sq_slice getter accepts only
> > two indexes - from,
> > > to, but not a step (which would solve the
> > issue).
> > 
> The sq_slice slot is deprecated, just like the
> __getslice__() method on the 
> Python side. Instead, implement sq_item to accept
> a slice object in addition to 
> integer indices.
> 
> http://docs.python.org/c-api/slice.html
> 
> -- 
> Robert Kern
> 
> "I have come to believe that the whole world is an
> enigma, a harmless enigma
> that is made terrible by our own mad attempt to
> interpret it as though it had
> an underlying truth."
> -- Umberto Eco
> 
> -- 
> http://mail.python.org/mailman/listinfo/python-list
> 




-- 
Tradiční i moderní adventní a novoroční zvyky, sváteční jídlo a
pití, výzdoba a dárky... - čtěte vánoční a silvestrovský speciál
portálu VOLNÝ.cz na http://web.volny.cz/data/click.php?id=1301

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Slices when extending python with C++

[Robert Kern]

On 12/28/11 1:01 PM, roze...@volny.cz wrote:

Dear Robert,

thank you very much for your answer. I understand what you mean and
I have looked at slice object and C-api methods it provides. It
should be easy to implement it.

The only question is how exactly yo implement the general getter,
since sq_item you mention (assume you mean
PySequenceMethods.sq_item) has the following signature:

PyObject * (* ssizeargfunc)(PyObject *, Py_ssize_t)

accepting Py_ssize_t as the index, not a PyObject * which would hold
the slice.

So, how exactly to implement the getter? As a general method named
__getitem__ registered in PyMethodDef? Or in another way?


Sorry, PyMappingMethods.mp_subscript is the general function that you need to 
implement.


--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

--
http://mail.python.org/mailman/listinfo/python-list

Online Data Entry Jobs Without Investment http://ponlinejobs.yolasite.com/

[PRABHAKARAN K]

Online Data Entry Jobs Without Investment
http://ponlinejobs.yolasite.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Online Data Entry Jobs Without Investment http://ponlinejobs.yolasite.com/

[PRABHAKARAN K]

Online Data Entry Jobs Without Investment
http://ponlinejobs.yolasite.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: RSA and Cryptography in PYTHON

[Andrew Berg]

On 12/27/2011 5:45 PM, 8 Dihedral wrote:

I am getting lousy in the news group in my writing?

I mean the non-trivial decoding of the key decomposition.
Of course RSA is symmetric in encoding and decoding of data.

You really are a markov chain bot.

--
CPython 3.2.2 | Windows NT 6.1.7601.17640
--
http://mail.python.org/mailman/listinfo/python-list

Global variables in a C extension for Python

[Lorenzo Di Gregorio]

Hello,

I've written a C extension for Python which works so far, but now I've
stumbled onto a simple problem for which I just can't find any example
on the web, so here I am crying for help ;-)

I'll trying to reduce the problem to a minimal example.  Let's say I
need to call from Python functions of a C program like:

static int counter = 0;
void do_something(...) {
... counter++; ...
}
void do_something_else(...) {
... counter++; ...
}

So they access a common global variable.  I've written the wrappers
for the functions, but I'd like to place "counter" in the module's
space and have wrappers accessing it like self->counter.  I do not
need to make "counter" visible to Python, I just need the global
static variable available for C.

I've got somehow a clue of how this should work, but not much more
than a clue, and I'd appreciate to see a simple example.

Best Regards,
Lorenzo
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Which libraries for Python 2.5.2

[W. eWatson]

On 12/27/2011 7:31 PM, W. eWatson wrote:

On 12/27/2011 6:27 PM, Ian Kelly wrote:

On Tue, Dec 27, 2011 at 6:21 PM, W. eWatson
wrote:

Well, it found several problems. These DLLs
MSVCP1
EFSADU
MSJAVA.


I'm guessing MSVCP1 is a typo for MSVCP71? If that is missing then
that is probably the culprit. That DLL is the C runtime library. It
is supposed to be shipped with applications that need it, but it is so
ubiquitous that it is often assumed to be present or forgotten. You
can download it from
http://www.dll-files.com/dllindex/dll-files.shtml?msvcp71 (or just
find it on another Windows XP PC) and copy it into
C:\Windows\System32. Don't forget to run regsvr32 to register it.

HTH,
Ian

You are very likely right about the spelling. I wrote it down, and
carried it to this PC. Sometimes I can't read my own writing.


...
Well, thing went slightly awry. The link gave me two choices. Download 
msv...dll fixer, and download fixer. I took the latter. However, just 
checking on the other one, found that I got the same exe file. I 
installed it on the XP PC, and pressed what looked like a reasonable 
place to start. It would download the dll, and register it.


Well, it seemed more interested in the registry. It scanned four areas 
of the registry, and found 123 problems in total. To fix them would 
require buying something.


I noticed a large button near the top that said download dll. It found 
one the internet, and guess what? More purchase for the download.


It seems like dll-fixer has a corner on the market.

I found this 
, 
but he almost has too much to say. He issues a warning about getting a 
dll off the web. He does offer this.


Run the sfc /scannow System File Checker command to replace a missing or 
corrupt copy of the msvcp71.dll file. If this DLL file is provided my 
Microsoft, the System File Checker tool should restore it.


I guess I'm missing something here.

OK, I'm borrowing one from my XP laptop. Back later.



--
http://mail.python.org/mailman/listinfo/python-list

Re: Which libraries for Python 2.5.2

[W. eWatson]

A new dilemma. The PC XP in question with Python has the the msvcp71.dll 
file in System32. The one I took off my other laptop has a slightly 
newer one. Feb 2003 vs Aug 2003.


Perhaps the (python PC) has a corrupt one?

--
http://mail.python.org/mailman/listinfo/python-list

pls explain this flags use

[Tracubik]

Hi all,
i've found here (http://python-gtk-3-tutorial.readthedocs.org/en/latest/
layout.html#table) this code:

[quote]
If omitted, xoptions and yoptions defaults to 
Gtk.AttachOptions.EXPAND | Gtk.AttachOptions.FILL.
[end quote]

xoptions have 3 flags: EXPAND, FILL, SHRINK

so, how it is supposed to work?
it means that by default xoptions is set to EXPAND true, FILL true, 
SHRINK false?

how it work? "|" is used with bits afaik, so i suppouse the xoptions is 3 
bits?

and the default is 
EXPAND FILL SHRINK
  1  1 0

(or something similar)

so i have

AttachOptions.EXPAND = 100
AttachOptions.FILL   = 010

EXPAND|FILL = 100|010 = 110

is that right? 
so if i want EXPAND *and* FILL i have to make EXPAND *binary or* FILL?

i'm new at this sintassi so i'm trying to guess on my own, pls feel free 
to tell me if i'm wrong and where

thanks and best wishes
Medeo
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Which libraries for Python 2.5.2

[Ian Kelly]

On Wed, Dec 28, 2011 at 9:33 AM, W. eWatson  wrote:
> Well, thing went slightly awry. The link gave me two choices. Download
> msv...dll fixer, and download fixer. I took the latter. However, just
> checking on the other one, found that I got the same exe file. I installed
> it on the XP PC, and pressed what looked like a reasonable place to start.
> It would download the dll, and register it.
>
> Well, it seemed more interested in the registry. It scanned four areas of
> the registry, and found 123 problems in total. To fix them would require
> buying something.
>
> I noticed a large button near the top that said download dll. It found one
> the internet, and guess what? More purchase for the download.
>
> It seems like dll-fixer has a corner on the market.

Definitely don't download that spamware fixer program -- who knows
what that does?  You want the grey "Download zip-file" link, not the
not the flashy "Download fixer" ad links.  Anyway, it sounds like
you've found another copy of the DLL.

If I were you, I would uninstall that fixer ASAP and then run an
anti-malware and anti-virus tool or two, just in case.

> Run the sfc /scannow System File Checker command to replace a missing or
> corrupt copy of the msvcp71.dll file. If this DLL file is provided my
> Microsoft, the System File Checker tool should restore it.

I don't believe it is provided by Microsoft, but it wouldn't hurt to try.

> A new dilemma. The PC XP in question with Python has the the msvcp71.dll
> file in System32. The one I took off my other laptop has a slightly newer
> one. Feb 2003 vs Aug 2003.

Weird.  Try registering the existing dll, try replacing it with the
other one (be sure to back up the original first), etc.
-- 
http://mail.python.org/mailman/listinfo/python-list

Python app installs itself in two places - why?

[tinnews]

I have installed an application called pycocuma on my xubuntu 11.10
system.  It works OK and I'm aiming to develop it a little as its
'owner' has long since stopped work on it.

However I'm a little puzzled by the way it has installed itself (it's
a standard package from the Ubuntu repositories), all the python
source is installed in two places:-

/usr/lib/python2.7/dist-packages/pycocumalib
/usr/share/pyshared/pycocumalib

All the files in /usr/lib/python2.7/dist-packages/pycocumalib are
actually symbolic links to the ones in /usr/share/pyshared/pycocumalib
but I just wondered why they're in both places.

Is it just 'historic' or is there a good sound reason for it?

-- 
Chris Green
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Possible bug in string handling (with kludgy work-around)

[Lie Ryan]

On 12/28/2011 11:57 AM, Rick Johnson wrote:

On Dec 27, 3:38 pm, Terry Reedy  wrote:

On 12/27/2011 1:04 PM, Rick Johnson wrote:


But this brings up a very important topic. Why do we even need triple
quote string literals to span multiple lines? Good question, and one i
have never really mused on until now.


I have, and the reason I thought of is that people, including me, too
ofter forget or accidentally fail to properly close a string literal,


Yes, agreed.


Color coding editors make it easier to catch such errors, but they were
less common in 1991.


I would say the need for triple quote strings has passed long ago.
Like you say, since color lexers are ubiquitous now we don't need
them.


And there is still uncolored interactive mode.


I don't see interactive command line programming as a problem. I mean,
who drops into a cmd line and starts writing paragraphs of string
literals? Typically, one would just make a few one-liner calls here or
there. Also, un-terminated string literal errors can be very
aggravating. Not because they are difficult to fix, no, but because
they are difficult to find! -- and sending me an error message
like...

  "Exception: Un-terminated string literal meets EOF! line: 50,466,638"

... is about as helpful as a bullet in my head!

If the interpreter finds itself at EOF BEFORE a string closes, don't
you think it would be more helpful to include the currently "opened"
strings START POSITION also?


No it wouldn't. Once you get an unterminated string literal, the string 
would terminate at the next string opening. Then it would fuck the 
parser since it will try to parse what was supposed to be a string 
literal as a code. For example:


hello = 'bar'
s = "boo, I missed a quote here
print 'hello = ', hello, "; s = ", s

the parser would misleadingly show that you have an unclosed string 
literal here:


  vvv
print 'hello = ', hello, "; s = ", s
  ^^^

instead of on line 2. While an experienced programmer should be able to 
figure out what's wrong, I can see a beginner programmer trying to "fix" 
the problem like this:


print 'hello = ', hello, "; s = ", s"

and then complaining that print doesn't print.

Limiting string literals to one line limits the possibility of damage to 
a single line. You will still have the same problem if you missed to 
close triple-quoted string, but since triple-quoted string are much 
rarer and they're pretty eye-catching, this sort of error harder are 
much harder.


--
http://mail.python.org/mailman/listinfo/python-list

Re: pls explain this flags use

[Ian Kelly]

On Wed, Dec 28, 2011 at 10:16 AM, Tracubik  wrote:
> Hi all,
> i've found here (http://python-gtk-3-tutorial.readthedocs.org/en/latest/
> layout.html#table) this code:
>
> [quote]
> If omitted, xoptions and yoptions defaults to
> Gtk.AttachOptions.EXPAND | Gtk.AttachOptions.FILL.
> [end quote]
>
> xoptions have 3 flags: EXPAND, FILL, SHRINK
>
> so, how it is supposed to work?
> it means that by default xoptions is set to EXPAND true, FILL true,
> SHRINK false?

Yes.

> how it work? "|" is used with bits afaik, so i suppouse the xoptions is 3
> bits?

Yes.

> and the default is
> EXPAND FILL SHRINK
>  1      1     0
>
> (or something similar)
>
> so i have
>
> AttachOptions.EXPAND = 100
> AttachOptions.FILL   = 010
>
> EXPAND|FILL = 100|010 = 110
>
> is that right?
> so if i want EXPAND *and* FILL i have to make EXPAND *binary or* FILL?

Yes.  Binary or is used to set flags, binary and is used to test
whether specific flags are set, e.g.:

if options & AttachOptions.EXPAND:
# do something expandy
else:
# do something not expandy
-- 
http://mail.python.org/mailman/listinfo/python-list

reverse() is not working

[Nirmal Kumar]

I am trying to pass the id to thanks view through reverse. But it's not 
working. I'm getting this error

Reverse for 'reg.views.thanks' with arguments '(20,)' and keyword arguments 
'{}' not found.

I posted the question with the code in stackoverflow:

http://stackoverflow.com/questions/8648196/reverse-is-not-working

How can I transfer arguments from one function to another in views?. Is it a 
normal thing or I have to use any built in functions?

Thanks.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: reverse() is not working

[Lie Ryan]

On 12/29/2011 05:02 AM, Nirmal Kumar wrote:

I am trying to pass the id to thanks view through reverse. But it's not 
working. I'm getting this error

Reverse for 'reg.views.thanks' with arguments '(20,)' and keyword arguments 
'{}' not found.

I posted the question with the code in stackoverflow:

http://stackoverflow.com/questions/8648196/reverse-is-not-working

How can I transfer arguments from one function to another in views?. Is it a 
normal thing or I have to use any built in functions?

Thanks.


Welcome to Python Mailing List; your question is about django, django 
have their own mailing list, your question is probably better asked there.


--
http://mail.python.org/mailman/listinfo/python-list

Where does this readOne() method come from?

[tinnews]

In the (rather sparse) documentation for the vobject package it has,
in the section about parsing iCalendar objects, the following:-

Parsing iCalendar objects
=

To parse one top level component from an existing iCalendar stream or
string, use the readOne function:

>>> parsedCal = vobject.readOne(icalstream)
>>> parsedCal.vevent.dtstart.value
datetime.datetime(2006, 2, 16, 0, 0, tzinfo=tzutc())

Similarly, readComponents is a generator yielding one top level
component at a time from a stream or string.

>>> vobject.readComponents(icalstream).next().vevent.dtstart.value
datetime.datetime(2006, 2, 16, 0, 0, tzinfo=tzutc())

More examples can be found in source code doctests.


However *nowhere* can I find anything that tells me what or where the
readOne() is.  It's not to be found in the full epydoc API
documentation for vobject (or, at least, I can't find it).

All I want to do is read a .ics file and parse it.  I used to use the
icalendar package but that seems less well supported than vobject so
I'm trying to use vobject instead but I'm not getting far at present.

It sort of feels like "everyone knows what readOne() is", but I don't! :-)

-- 
Chris Green
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py-dea: Streamline string literals now!

[Rick Johnson]

On Dec 28, 12:58 am, Steven D'Aprano  wrote:
> On Tue, 27 Dec 2011 21:34:19 -0800, Rick Johnson wrote:

> > I am also thinking that ANY quote char is a bad choice for string
> > literal delimiters. Why? Well because it is often necessary to embed
> > single or double quotes into a string literal. We need to use a
> > delimiter that is not a current delimiter elsewhere in Python, and also,
> > is a very rare char. I believe Mr Ewing found that perfect char in his
> > "Multi-line uber raw string literals!" (Just scroll down a bit at this
> > link)...
>
> >    http://www.cosc.canterbury.ac.nz/greg.ewing/python/ideas.html
>
> Not surprisingly, you haven't thought this through. I'm sure Greg Ewing
> has, which is why he hasn't proposed *replacing* string delimiters with
> his multi-line format. That's why he proposed it as a *statement* and not
> string-builder syntax.
>
> Without an end-delimiter, how do you embed string literals in expressions?

Did you even read what i wrote? And if you did, you missed the point!

My point was... while Greg's idea is nice, it is not the answer.
HOWEVER, he did find the perfect char, and that char is the pipe! -->
|

mlstr = |||
this is a
multi line sting that is
delimited by "triple pipes". Or we
could just 'single pipes' if we like, however, i think
the "triple pipe' is easier to see. Since the pipe char
is so rare in Python source, it becomes the obvious
choice. And, best of all, no more worries about
"embedded quotes". YAY!
|||

slstr = |this is a single line string|

The point is people, we should be using string delimiters that are
ANYTHING besides " and '. Stop being a sheep and use your brain!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py-dea: Streamline string literals now!

[Dominic Binks]

On 12/28/2011 11:36 AM, Rick Johnson wrote:

On Dec 28, 12:58 am, Steven D'Aprano  wrote:

On Tue, 27 Dec 2011 21:34:19 -0800, Rick Johnson wrote:



I am also thinking that ANY quote char is a bad choice for string
literal delimiters. Why? Well because it is often necessary to embed
single or double quotes into a string literal. We need to use a
delimiter that is not a current delimiter elsewhere in Python, and also,
is a very rare char. I believe Mr Ewing found that perfect char in his
"Multi-line uber raw string literals!" (Just scroll down a bit at this
link)...



http://www.cosc.canterbury.ac.nz/greg.ewing/python/ideas.html


Not surprisingly, you haven't thought this through. I'm sure Greg Ewing
has, which is why he hasn't proposed *replacing* string delimiters with
his multi-line format. That's why he proposed it as a *statement* and not
string-builder syntax.

Without an end-delimiter, how do you embed string literals in expressions?


Did you even read what i wrote? And if you did, you missed the point!

My point was... while Greg's idea is nice, it is not the answer.
HOWEVER, he did find the perfect char, and that char is the pipe! -->
|

mlstr = |||
this is a
multi line sting that is
delimited by "triple pipes". Or we
could just 'single pipes' if we like, however, i think
the "triple pipe' is easier to see. Since the pipe char
is so rare in Python source, it becomes the obvious
choice. And, best of all, no more worries about
"embedded quotes". YAY!
|||

slstr = |this is a single line string|

The point is people, we should be using string delimiters that are
ANYTHING besides " and '. Stop being a sheep and use your brain!


I disagree that quotes are a bad thing.  Most programming languages use 
+, -, / and * for arithmentic operations (* is closest character on a 
keyboard to x that is not the letter ex).  Why do they choose to do 
this?  It's actually a lot more work for the language implementer(s) to 
do this rather than simply providing functions add(x,y), subtract(x,y), 
divide(x,y) and multiply(x,y).


The answer is very simple - convention.  We use these symbols in 
mathematics and so it's much more convenient to follow through the 
mathematical convention.  The learning curve is much lower (and it's 
less typing).  After all experienced programmers know this is what is 
going on under the hood in pretty much all programming languages. 
Compilers are just making it easy for us.


While it may indeed make sense to use a different character for 
delimiting strings, in English we use " to delimit spoken words in a 
narrative.  Since strings most closely resemble spoken words from the 
point of view a programming language, using double quotes is a sensible 
choice since it eases learning.


Convention is a very strong thing to argue against (not to mention huge 
code breakage as a result of such a change).


Personally, I try to ensure I use consistency in the way I use the 
different quoting mechanisms, but that's just a personal choice. 
Sometimes that leads me to less pleasant looking strings, but I believe 
the consistency of style makes it easier to read.


I think this proposal falls in the, let's make python case-insensitive 
kind of idea - it's never going to happen cause it offers very little 
benefit at huge cost.


And I'm not going to contribute to this thread any further cause it's a 
pointless waste of my time to write it and others time to read it.


--
Dominic Binks: dbi...@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
--
http://mail.python.org/mailman/listinfo/python-list

Re: Py-dea: Streamline string literals now!

[Lie Ryan]

On 12/29/2011 06:36 AM, Rick Johnson wrote:


mlstr = |||
this is a
multi line sting that is
delimited by "triple pipes". Or we
could just 'single pipes' if we like, however, i think
the "triple pipe' is easier to see. Since the pipe char
is so rare in Python source, it becomes the obvious
choice. And, best of all, no more worries about
"embedded quotes". YAY!
|||

slstr = |this is a single line string|

The point is people, we should be using string delimiters that are
ANYTHING besides " and '. Stop being a sheep and use your brain!


This will incur the wrath of all linux/unix sysadmins all over the 
world. You are just replacing one problem with another; in your 
obliviousness, you had just missed the very obvious fact that once you 
replace quotes with pipes, quotes is extremely rare in Python (in fact 
you won't be seeing any quotes except inside string literals).


--
http://mail.python.org/mailman/listinfo/python-list

Re: Where does this readOne() method come from?

[Terry Reedy]

On 12/28/2011 2:04 PM, tinn...@isbd.co.uk wrote:

In the (rather sparse) documentation for the vobject package it has,
in the section about parsing iCalendar objects, the following:-

 Parsing iCalendar objects
 =

 To parse one top level component from an existing iCalendar stream or
 string, use the readOne function:

 >>>  parsedCal = vobject.readOne(icalstream)


It is obviously supposed to come from the 'vobject' package, whatever 
that is. I have never heard of vobject before, though. Try reading the 
source if the doc is limited. Or ask the author or mailing list if there 
is one.



It sort of feels like "everyone knows what readOne() is",


Nope

PS You already know the answer to the question you asked in the subject 
line. Better would have been "What is the vobject.readOne function?" to 
catch the eye of someone who *does* know something about vobject.


--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

Re: Where does this readOne() method come from?

[Chris Angelico]

On Thu, Dec 29, 2011 at 6:04 AM,   wrote:
> In the (rather sparse) documentation for the vobject package it has,
> in the section about parsing iCalendar objects, the following:-
>
>    >>> parsedCal = vobject.readOne(icalstream)

Presumably you have this vobject package. Assuming it's installed
correctly, all you need to do is:

import vobject

and then vobject.readOne should be available.

Chris Angelico
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py-dea: Streamline string literals now!

[Ian Kelly]

On Wed, Dec 28, 2011 at 12:36 PM, Rick Johnson
 wrote:
> My point was... while Greg's idea is nice, it is not the answer.
> HOWEVER, he did find the perfect char, and that char is the pipe! -->
> |
>
> mlstr = |||
> this is a
> multi line sting that is
> delimited by "triple pipes". Or we
> could just 'single pipes' if we like, however, i think
> the "triple pipe' is easier to see. Since the pipe char
> is so rare in Python source, it becomes the obvious
> choice. And, best of all, no more worries about
> "embedded quotes". YAY!
> |||
>
> slstr = |this is a single line string|
>
> The point is people, we should be using string delimiters that are
> ANYTHING besides " and '. Stop being a sheep and use your brain!

So those who do shell scripting from Python might replace this:

subprocess.call("cat {0} | awk '/foo|bar/ {print $3;}' | sort | uniq
>{1}".format(infile, outfile), shell=True)

with this:

subprocess.call(|cat {0} \| awk '/foo\|bar/ {print $3;}' \| sort \|
uniq >{1}|.format(infile, outfile), shell=True)

or if we combine Rick's string escaping proposal:

subprocess.call(|cat {0}  awk '/foobar/ {print $3;}'
 sort  uniq {1}|.format(infile, outfile), shell=True)

Yeah, that's so much better.  I especially like how nice and readable
the regex is now.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py-dea: Streamline string literals now!

[Lie Ryan]

On 12/28/2011 04:34 PM, Rick Johnson wrote:

On Dec 27, 9:49 pm, Rick Johnson  wrote:


The fact is...even with the multi-line issue solved, we still have two
forms of literal delimiters that encompass two characters resulting in
*four* possible legal combinations of the exact same string! I don't
know about you guys, but i am not a big fan of Tim Towtdi.


actually i was a bit hasty with that statment and underestimated the
actual number of possiblities.

1) "this is a string"
2) 'this is a string'
3) r"this is a string"
4) r'this is a string'
5) '''this is a string'''
6) """this is a string"""
7) r'''this is a string'''
8) r"""this is a string"""


you missed u"nicode" string and b"yte" string, each of them available in 
both single and double quote flavor and single and triple quote flavor. 
Also, it's possible to mix them together ur"unicode raw string" or 
br"byte raw string", they are also in single and double quote flavor and 
single and triple quote flavor. And of course, I can't believe you 
forget Guido's favourite version, g"", available in musical and sirloin 
cloth flavor.


--
http://mail.python.org/mailman/listinfo/python-list

Re: Which libraries for Python 2.5.2

[W. eWatson]

On 12/28/2011 9:37 AM, Ian Kelly wrote:

On Wed, Dec 28, 2011 at 9:33 AM, W. eWatson  wrote:

Well, thing went slightly awry. The link gave me two choices. Download
msv...dll fixer, and download fixer. I took the latter. However, just
checking on the other one, found that I got the same exe file. I installed
it on the XP PC, and pressed what looked like a reasonable place to start.
It would download the dll, and register it.

Well, it seemed more interested in the registry. It scanned four areas of
the registry, and found 123 problems in total. To fix them would require
buying something.

I noticed a large button near the top that said download dll. It found one
the internet, and guess what? More purchase for the download.

It seems like dll-fixer has a corner on the market.


Definitely don't download that spamware fixer program -- who knows
what that does?  You want the grey "Download zip-file" link, not the
not the flashy "Download fixer" ad links.  Anyway, it sounds like
you've found another copy of the DLL.

If I were you, I would uninstall that fixer ASAP and then run an
anti-malware and anti-virus tool or two, just in case.


Run the sfc /scannow System File Checker command to replace a missing or
corrupt copy of the msvcp71.dll file. If this DLL file is provided my
Microsoft, the System File Checker tool should restore it.


I don't believe it is provided by Microsoft, but it wouldn't hurt to try.


A new dilemma. The PC XP in question with Python has the the msvcp71.dll
file in System32. The one I took off my other laptop has a slightly newer
one. Feb 2003 vs Aug 2003.


Weird.  Try registering the existing dll, try replacing it with the
other one (be sure to back up the original first), etc.


I haven't installed the newer version yet, Aug 2003. I thought I'd see 
what happened if I entered sfc /scannow.  Whatever, happened the black 
window flashed by in a split second.


Somehow this doesn't seem helpful 
. 
Although, 20 lines down or so it says:
If sfc discovers that a protected file has been overwritten, it 
retrieves the correct version of the file from the 
%systemroot%\system32\dllcache folder, and then replaces the incorrect 
file.


I'm going to run this by a XP NG.


--
http://mail.python.org/mailman/listinfo/python-list

Re: Py-dea: Streamline string literals now!

[python]

Lie,

> And of course, I can't believe you forget Guido's favourite version, g"", 
> available in musical and sirloin cloth flavor.

LMAO! That was brilliant! :)

Cheers!
Malcolm
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py-dea: Streamline string literals now!

[Nathan Rice]

Quotes are obnoxious in the nesting sense because everyone uses quotes
for string delimiters.  By the same token, quotes are wonderful
because not only are they intuitive to programmers, but they are
intuitive in general.  Parenthesis are pretty much in the same boat...
I *HATE* them nested, but they are so intuitive that replacing them is
a non starter;  Just write code that doesn't nest parenthesis.

Nathan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py-dea: Streamline string literals now!

[Chris Angelico]

On Thu, Dec 29, 2011 at 8:24 AM, Nathan Rice
 wrote:
> Quotes are obnoxious in the nesting sense because everyone uses quotes
> for string delimiters.  By the same token, quotes are wonderful
> because not only are they intuitive to programmers, but they are
> intuitive in general.  Parenthesis are pretty much in the same boat...
> I *HATE* them nested, but they are so intuitive that replacing them is
> a non starter;  Just write code that doesn't nest parenthesis.

Parentheses have different starting and ending delimiters and must be
'properly nested' (ie there must be exactly-matching inner parens
inside any given set of outer parens (note that English has similar
rules - you can't mis-nest parentheses (at any depth) in either
language)). You can't guarantee the same about quoted strings -
suppose the starting delimiter were ' and the ending " (or vice
versa), it still wouldn't deal with the issue of coming across an
apostrophe inside a quoted string.

In actual fact, the real problem is that quoted strings need to be
able to contain _anything_. The only true solution to that is
length-provided strings:

s = "4spam
q = "14Hello, world!\n

This works beautifully in interchange formats, but rather poorly in
source code (or, for that matter, anything editable).

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py-dea: Streamline string literals now!

[Nathan Rice]

On Wed, Dec 28, 2011 at 4:42 PM, Chris Angelico  wrote:
> On Thu, Dec 29, 2011 at 8:24 AM, Nathan Rice
>  wrote:
>> Quotes are obnoxious in the nesting sense because everyone uses quotes
>> for string delimiters.  By the same token, quotes are wonderful
>> because not only are they intuitive to programmers, but they are
>> intuitive in general.  Parenthesis are pretty much in the same boat...
>> I *HATE* them nested, but they are so intuitive that replacing them is
>> a non starter;  Just write code that doesn't nest parenthesis.
>
> Parentheses have different starting and ending delimiters and must be
> 'properly nested' (ie there must be exactly-matching inner parens
> inside any given set of outer parens (note that English has similar
> rules - you can't mis-nest parentheses (at any depth) in either
> language)). You can't guarantee the same about quoted strings -
> suppose the starting delimiter were ' and the ending " (or vice
> versa), it still wouldn't deal with the issue of coming across an
> apostrophe inside a quoted string.

I think you read more into my statement than was intended.  Parens are
bad like nested quotes are bad in the sense that they made statements
difficult to read and confusing.

While it is entirely possible to parse nested strings automatically in
a probabilistic manner with nearly flawless accuracy by examining
everything between the start and end of the line, generally I feel
that people are uncomfortable with probabilistic techniques in the
realm of programming :)  Best just to make the user be explicit.

Nathan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pythonification of the asterisk-based collection packing/unpacking syntax

[Lie Ryan]

On 12/28/2011 11:08 PM, Eelco wrote:

I personally feel any performance benefits are but a plus; they are
not the motivating factor for this idea. I simply like the added
verbosity and explicitness, thats the bottom line.


Any performance benefits are a plus, I agree, as long as it doesn't make 
my language looks like Perl. Now get off my lawn!


--
http://mail.python.org/mailman/listinfo/python-list

importing MySQLdb

[Dilara Ally]

Hi All

I'm trying to import the MySQLdb for python.  I downloaded the proper 
setuptools egg (ver2.7) for a Mac with OSX10.6


I then downloaded the MySQL-python-1.2.3 and ran the following commands

python setup.py build
sudo python setup.py install

Then to test that the module was properly loaded I used the interactive 
python prompt ad ran the following command:


import MySQLdb

The error message read:

Traceback (most recent call last):
  File "", line 1, in 
  File "MySQLdb/__init__.py", line 19, in 
import _mysql
  File "build/bdist.macosx-10.6-intel/egg/_mysql.py", line 7, in 
  File "build/bdist.macosx-10.6-intel/egg/_mysql.py", line 6, in 
__bootstrap__
ImportError: 
dlopen(/Users/dally/.python-eggs/MySQL_python-1.2.3-py2.7-macosx-10.6-intel.egg-tmp/_mysql.so, 
2): Library not loaded: libmysqlclient.18.dylib
  Referenced from: 
/Users/dally/.python-eggs/MySQL_python-1.2.3-py2.7-macosx-10.6-intel.egg-tmp/_mysql.so

  Reason: image not found

Does anyone have any ideas on how to fix this problem?  Any help will be 
greatly appreciated!


Dilara

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py-dea: Streamline string literals now!

[Steven D'Aprano]

On Wed, 28 Dec 2011 11:36:17 -0800, Rick Johnson wrote:

> The point is people, we should be using string delimiters that are
> ANYTHING besides " and '. Stop being a sheep and use your brain!

"ANYTHING", hey?

I propose we use ئ and ร as the opening and closing string delimiters. 
Problem solved!

Thank you Rick for yet another brilliant, well-thought-out idea. I look 
forward to seeing your fork of Python with this change. How is it going? 
I hope you aren't going to disappoint the legions of your fans who are 
relying on you to save the Python community from neglect.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py-dea: Streamline string literals now!

[Chris Angelico]

On Thu, Dec 29, 2011 at 9:54 AM, Steven D'Aprano
 wrote:
> Thank you Rick for yet another brilliant, well-thought-out idea. I look
> forward to seeing your fork of Python with this change. How is it going?
> I hope you aren't going to disappoint the legions of your fans who are
> relying on you to save the Python community from neglect.

But Steven, the shocking state of IDLE has utterly destroyed any
reputation Python may have had. There's not going to be any community
left to neglect, soon!

That said, though, the new string delimiters will solve many problems.
We should adopt a strict policy: all syntactic elements MUST be
comprised of non-ASCII characters, thus allowing all ASCII characters
to represent themselves literally. I'm not sure what "representing
themselves literally" would mean, since strings already have perfect
delimiters, but it seems like a good policy.

By the way, doubling the delimiter works for nesting strings. ئئ and
รร look just fine.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Slices when extending python with C++

[rozelak]

Great, it's working! Thank you very much, Robert!
Dan T.

- PŮVODNÍ ZPRÁVA -
Od: "Robert Kern" 
Komu: python-list@python.org
Předmět: Re: Slices when extending python with C++
Datum: 28.12.2011 - 14:18:36

> On 12/28/11 1:01 PM, roze...@volny.cz wrote:
> > Dear Robert,
> >
> > thank you very much for your answer. I
> > understand what you mean and
> > > I have looked at slice object and C-api methods
> > it provides. It
> > > should be easy to implement it.
> >
> > The only question is how exactly yo implement
> > the general getter,
> > > since sq_item you mention (assume you mean
> > PySequenceMethods.sq_item) has the following
> > signature:
> > >
> > PyObject * (* ssizeargfunc)(PyObject *,
> > Py_ssize_t)
> > >
> > accepting Py_ssize_t as the index, not a
> > PyObject * which would hold
> > > the slice.
> >
> > So, how exactly to implement the getter? As a
> > general method named
> > > __getitem__ registered in PyMethodDef? Or in
> > another way?
> > 
> Sorry, PyMappingMethods.mp_subscript is the
> general function that you need to 
> implement.
> 
> -- 
> Robert Kern
> 
> "I have come to believe that the whole world is an
> enigma, a harmless enigma
> that is made terrible by our own mad attempt to
> interpret it as though it had
> an underlying truth."
> -- Umberto Eco
> 
> -- 
> http://mail.python.org/mailman/listinfo/python-list
> 


-- 
Tradiční i moderní adventní a novoroční zvyky, sváteční jídlo a
pití, výzdoba a dárky... - čtěte vánoční a silvestrovský speciál
portálu VOLNÝ.cz na http://web.volny.cz/data/click.php?id=1301

-- 
http://mail.python.org/mailman/listinfo/python-list

Get Class properties

[Emeka]

Hello All,

Say I have a class like below

  class Town:
 state = StateClass()
 cities = CityClass()


Is there way to introspect such that one can list the properties keys and
their values in such a way that it would look like playing around
dictionary ?

Regards,
Janus
-- 
*Satajanus  Nig. Ltd


*
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Get Class properties

[Chris Angelico]

On Wed, Dec 28, 2011 at 11:13 PM, Emeka  wrote:
> Hello All,
>
> I have seen what I am looking for.. __dict__.
>

Yep! You may also want to look at the dir() function.

Chris Angelico
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py-dea: Streamline string literals now!

[Dan Sommers]

On Wed, 28 Dec 2011 22:54:16 +, Steven D'Aprano wrote:

> On Wed, 28 Dec 2011 11:36:17 -0800, Rick Johnson wrote:
> 
>> The point is people, we should be using string delimiters that are
>> ANYTHING besides " and '. Stop being a sheep and use your brain!
> 
> "ANYTHING", hey?
> 
> I propose we use ئ and ร as the opening and closing string delimiters.
> Problem solved!

Why stop at pre-determined, literal delimiters?  That's way too easy on 
the parser, whether that parser is a computer or a person.

__string_delimiter__ = Ω  # magic syntax; no quotes needed

x = ΩhelloΩ

__string_delimiter__ = #  # that first # isn't a comment marker

x = # this isn't a comment; it's part of the string
this is a multi-line string
#

__string_delimiter__ = ''  # the delimiter is delimited by whitespace
# now I can have comments, again, too

x = ''"hello"''  # now x contains two double-quote characters

I'm sure that the implementation is trivial, and it's so much easier to 
write strings that contain quotes (not to mention how easy it is to read 
those strings back later).

-- 
Dan

-- 
http://mail.python.org/mailman/listinfo/python-list

logging.getLogger( __name__ )

[Ram]

How does this line work? How do I get my logger to point to a file to
be named as /tmp/modulename.log : I can do this using inspect, but
there probably is a better way?

Thanks,
--Ram
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Which libraries for Python 2.5.2

[W. eWatson]

On 12/28/2011 12:55 PM, W. eWatson wrote:

On 12/28/2011 9:37 AM, Ian Kelly wrote:

On Wed, Dec 28, 2011 at 9:33 AM, W. eWatson
wrote:

Well, thing went slightly awry. The link gave me two choices. Download
msv...dll fixer, and download fixer. I took the latter. However, just
checking on the other one, found that I got the same exe file. I
installed
it on the XP PC, and pressed what looked like a reasonable place to
start.
It would download the dll, and register it.

Well, it seemed more interested in the registry. It scanned four
areas of
the registry, and found 123 problems in total. To fix them would require
buying something.

I noticed a large button near the top that said download dll. It
found one
the internet, and guess what? More purchase for the download.

It seems like dll-fixer has a corner on the market.


Definitely don't download that spamware fixer program -- who knows
what that does? You want the grey "Download zip-file" link, not the
not the flashy "Download fixer" ad links. Anyway, it sounds like
you've found another copy of the DLL.

If I were you, I would uninstall that fixer ASAP and then run an
anti-malware and anti-virus tool or two, just in case.


Run the sfc /scannow System File Checker command to replace a missing or
corrupt copy of the msvcp71.dll file. If this DLL file is provided my
Microsoft, the System File Checker tool should restore it.


I don't believe it is provided by Microsoft, but it wouldn't hurt to try.


A new dilemma. The PC XP in question with Python has the the msvcp71.dll
file in System32. The one I took off my other laptop has a slightly
newer
one. Feb 2003 vs Aug 2003.


Weird. Try registering the existing dll, try replacing it with the
other one (be sure to back up the original first), etc.


I haven't installed the newer version yet, Aug 2003. I thought I'd see
what happened if I entered sfc /scannow. Whatever, happened the black
window flashed by in a split second.

Somehow this doesn't seem helpful
.
Although, 20 lines down or so it says:
If sfc discovers that a protected file has been overwritten, it
retrieves the correct version of the file from the
%systemroot%\system32\dllcache folder, and then replaces the incorrect
file.

I'm going to run this by a XP NG.



That certainly didn't help.

I'm going to save the msvcp71.dll from the Python laptop somewhere, then 
insert the one from my other XP laptop. Finally, I'll register it. 
regsvr32. Just to review, I presume not from cmd, but Run?

--
http://mail.python.org/mailman/listinfo/python-list

Re: Which libraries for Python 2.5.2

[Benjamin Kaplan]

On Wed, Dec 28, 2011 at 10:04 PM, W. eWatson  wrote:
> On 12/28/2011 12:55 PM, W. eWatson wrote:
>>
>> On 12/28/2011 9:37 AM, Ian Kelly wrote:
>>>
>>> On Wed, Dec 28, 2011 at 9:33 AM, W. eWatson
>>> wrote:

 Well, thing went slightly awry. The link gave me two choices. Download
 msv...dll fixer, and download fixer. I took the latter. However, just
 checking on the other one, found that I got the same exe file. I
 installed
 it on the XP PC, and pressed what looked like a reasonable place to
 start.
 It would download the dll, and register it.

 Well, it seemed more interested in the registry. It scanned four
 areas of
 the registry, and found 123 problems in total. To fix them would require
 buying something.

 I noticed a large button near the top that said download dll. It
 found one
 the internet, and guess what? More purchase for the download.

 It seems like dll-fixer has a corner on the market.
>>>
>>>
>>> Definitely don't download that spamware fixer program -- who knows
>>> what that does? You want the grey "Download zip-file" link, not the
>>> not the flashy "Download fixer" ad links. Anyway, it sounds like
>>> you've found another copy of the DLL.
>>>
>>> If I were you, I would uninstall that fixer ASAP and then run an
>>> anti-malware and anti-virus tool or two, just in case.
>>>
 Run the sfc /scannow System File Checker command to replace a missing or
 corrupt copy of the msvcp71.dll file. If this DLL file is provided my
 Microsoft, the System File Checker tool should restore it.
>>>
>>>
>>> I don't believe it is provided by Microsoft, but it wouldn't hurt to try.
>>>
 A new dilemma. The PC XP in question with Python has the the msvcp71.dll
 file in System32. The one I took off my other laptop has a slightly
 newer
 one. Feb 2003 vs Aug 2003.
>>>
>>>
>>> Weird. Try registering the existing dll, try replacing it with the
>>> other one (be sure to back up the original first), etc.
>>
>>
>> I haven't installed the newer version yet, Aug 2003. I thought I'd see
>> what happened if I entered sfc /scannow. Whatever, happened the black
>> window flashed by in a split second.
>>
>> Somehow this doesn't seem helpful
>>
>> .
>> Although, 20 lines down or so it says:
>> If sfc discovers that a protected file has been overwritten, it
>> retrieves the correct version of the file from the
>> %systemroot%\system32\dllcache folder, and then replaces the incorrect
>> file.
>>
>> I'm going to run this by a XP NG.
>>
>>
> That certainly didn't help.
>
> I'm going to save the msvcp71.dll from the Python laptop somewhere, then
> insert the one from my other XP laptop. Finally, I'll register it. regsvr32.
> Just to review, I presume not from cmd, but Run?

It should work from either but I prefer to use cmd in case there's an
error message.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Which libraries for Python 2.5.2

[Michael Torrie]

On 12/28/2011 08:04 PM, W. eWatson wrote:
> I'm going to save the msvcp71.dll from the Python laptop somewhere, then 
> insert the one from my other XP laptop. Finally, I'll register it. 
> regsvr32. Just to review, I presume not from cmd, but Run?

Seems like the bulk of your problems are coming from not using cmd
(flashing black error windows).  Anything non-GUI that could return an
error message should be done from cmd.  The Run dialog is mainly to be
used to launch a cmd window!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Which libraries for Python 2.5.2

[W. eWatson]

On 12/28/2011 9:09 PM, Michael Torrie wrote:

On 12/28/2011 08:04 PM, W. eWatson wrote:

I'm going to save the msvcp71.dll from the Python laptop somewhere, then
insert the one from my other XP laptop. Finally, I'll register it.
regsvr32. Just to review, I presume not from cmd, but Run?


Seems like the bulk of your problems are coming from not using cmd
(flashing black error windows).  Anything non-GUI that could return an
error message should be done from cmd.  The Run dialog is mainly to be
used to launch a cmd window!

it appears more than just regsvr32 is need. Alone it fails with a msg. 
It needs an argument. I tried


regsvr32 msvcp71.dll

It didn't like that either. Got "msvcp71.dll was located but the dll 
server entry was not found. File could not be registered."


Arguments are /u,/s/i/n.
--
http://mail.python.org/mailman/listinfo/python-list

Online Data Entry Jobs Without Investment http://ponlinejobs.yolasite.com/

[prabhakaran k]

Online Data Entry Jobs Without Investment
http://ponlinejobs.yolasite.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Online Data Entry Jobs Without Investment http://ponlinejobs.yolasite.com/

[prabhakaran k]

Online Data Entry Jobs Without Investment
http://ponlinejobs.yolasite.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Which libraries for Python 2.5.2

[Chris Angelico]

On Thu, Dec 29, 2011 at 4:09 PM, Michael Torrie  wrote:
> The Run dialog is mainly to be
> used to launch a cmd window!

On any Windows computer that I use, that's strictly true. The only
program I ever Start|Run is cmd.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list