Re: .format vs. %

[Ian Kelly]

On Mon, Jan 2, 2012 at 11:15 PM, Steven D'Aprano
 wrote:
> Which is exactly why it is not deprecated: it doesn't say it is
> deprecated and has no timeline for removal. It may not even be removed:
> "may" go away is not "will" go away.
>
> Going around saying that features are deprecated just because they may
> (or may not) some day in the distant future become deprecated is FUD. It
> simply isn't true that % formatting is deprecated: Python Dev has a
> formal process for deprecating code, and that process has not been
> applied to % and there are no plans to do so in the foreseeable future.

So it's not formally deprecated, but it is nonetheless labeled
obsolete and discouraged, or "informally deprecated" if you will.

I'm not sure it's true that "there are no plans to do so in the
foreseeable future."  According to the release notes from Python 3.0,
% formatting was supposed to be deprecated in Python 3.1.  Why that
didn't happen, I don't know.  Maybe there was a discussion on py-dev
where it was decided that % formatting would not be deprecated after
all (in which case the misleading "obsolete" note really ought to be
removed from the documentation).  Maybe that discussion has been
tabled for the time being.  Or maybe it hasn't been deprecated simply
because nobody has gotten around to actually doing it yet.

In any case the statement of obsolescence and the lack of clarity
about the feature's future is enough cause for me to avoid the
feature, although you of course are free to use it however you want.

> There is a huge code base using this feature, including the standard
> library, and Python does not arbitrarily deprecate features used by real
> code without good reason. Just because a number of Python devs want to
> encourage people to use format doesn't imply that % will go away any time
> before Python 4000.

The reason for deprecating it is because Python currently has no fewer
than three mechanisms for string formatting (not even including
ordinary string concatenation), which according to the Zen of Python
is two too many.  In my view, % formatting has a lot in common with
the print statement -- it's warty syntax that is better implemented as
a function.  In Python 3 we could have kept the print statement and
avoided breaking a feature commonly used by "real code" by adding the
print function as a supplement to the statement (probably with a
slightly different name).  But the devs went a step further and
actually removed the print statement, and IMO that was a good thing.
The same thing should be done with % formatting (although I agree on
one point, it likely won't happen before Python 4).

Cheers,
Ian
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Spamming PyPI with stupid packages

[Peter Otten]

Lie Ryan wrote:

> On 01/02/2012 11:20 PM, Peter Otten wrote:
>> Felinx Lee wrote:
>>
>>> I have removed those packages (girlfriend and others) from PyPI forever,
>>> I apologize for that.
>>
>> The thought police has won :(
> 
> I think the community has a right to defend themselves against trolls.
> If it's just bad naming, we can probably just laugh it off; but when a
> failed joke spans a half dozen module and just opens a browser to his
> website, there is no value for it to stay at PyPI. Additionally, it may
> fuel copycats: http://pypi.python.org/pypi/kimwoohyeon1/1.3.0 (do anyone
> have any idea who submitted that one?)

I think it's a judgment call.

"maybe policing uploads is worse than cluttering PyPI's disk space and RSS 
feed with dumb 1 KB packages." (Matt Chaput)

I'd drop the "maybe".


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

Re: Spamming PyPI with stupid packages

[Steven D'Aprano]

On Tue, 03 Jan 2012 08:59:53 +1100, Ben Finney wrote:

> Devin Jeanpierre  writes:
> 
>> > Nonsense. Felinx is free to make sexist jokes, and others are free to
>> > howl him down when he does so. PyPI has no obligation to be a
>> > platform to amplify anyone's prejudice.
>>
>> A module named "girlfriend" won't amplify anyone's prejudice. It is, at
>> that point, just a joke.
> 
> I agree that it's a joke. It is a joke at the expense of women:
> promoting the view that, like a car or a house (the other modules that
> were part of the joke), a girlfriend is a possession to be acquired.

How do you get that reading?

Yes, in the English language, we talk about "getting a girlfriend", but 
we also talk about "getting a boyfriend". Does that imply that *men* are 
nothing more than a possession to be acquired? Clearly not. There is no 
implication re social status -- we can talk about "the nation has finally 
got a king" without any implication that kings are low status, mere 
"possessions" to be acquired. 

If there is anything "offensive" about the "joke", it is the implication 
that women are shallow creatures only interested in men for their earning 
potential. But why should that be more offensive than the idea that men 
are so desperate for a relationship that they are happy to hand over 
their earnings to anything female that pretends an interest in them? The 
joke cuts both ways.

It is the nature of jokes to exaggerate character traits. In real life, 
many women *are* interested in the earning potential of men, not 
exclusive of all other factors of course, and many men *are* push-overs 
to any gold-digger with a pretty face. But neither is a universal trait: 
they are mere generalisations. 

There are exceptions, of course, people are complex and reality doesn't 
fit nicely into the pigeon holes we invent, but generalities do apply in 
general. We're lying to ourselves if we don't acknowledge the truth that 
in general the status of a man depends on his wealth and power and that 
of a woman on her fecundity, looks and youth. Acknowledging that reality 
is no more sexist than acknowledging the reality that on average men are 
bigger than women and that women can conceive but men can't.


Stan: I want to have babies.
Reg: You want to have babies?!?!
Stan: It's every man's right to have babies if he wants them.
Reg: But ... you can't HAVE babies!
Stan: Don't you oppress me!
Reg: I'm not oppressing you, Stan. You haven't got a womb! Where's the 
fetus gonna gestate? You gonna keep it in a box?

- Life of Brian



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

Re: Avoid race condition with Popen.send_signal

[Jérôme]

Mon, 2 Jan 2012 19:16:50 -0800 (PST)
Adam Skutt a écrit:

> No. It is possible (however unlikely) for EPERM to be legitimately
> returned in this case.  Anything other than EINVAL should be
> interpreted as "The child process is dead".  Hence why you should
> avoid sending the signal in the first place: the situations where you
> don't run the risk of possibly killing an innocent bystander are
> pretty narrow.  While unlikely on modern UNiX and Linux, IMO it's best
> to avoid the issue altogether whenever possible.

Should I understand that Popen.send_signal blindly sends the signal to the
process of PID Popen.pid, and therefore could kill a new process of the same
PID that would have been launched by the same user in another program ?

In other words, if a user launches my python program, which in its turn
launches a subprocess of PID N, then the subprocess dies, then the same user
launches a terminal that gets the same PID (N), what happens if my python
program calls Popen.send_signal(SIGINT) ? Does it kill the terminal ?

If so, I don't see how I can protect myself from that. Checking the process
is alive and then hoping that the time interval for the race condition is so
small that there are few chances for that to happen (because the OS
quarantines PID numbers for a while, for instance) ?

-- 
Jérôme
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Spamming PyPI with stupid packages

[Peter Otten]

Ben Finney wrote:

> The next time someone asks why the ratio of women becoming programmers
> is disproportionately low, please recall episodes where men here give
> defenses of jokes that objectify women.

What's that? The butterfly effect of diversity?

If you want more women in IT go to a local school and show the girls things 
they can do with a computer that they find fun and interesting. If you have 
a daughter try more Lego and less Barbies. 

Don't insist if it doesn't work out. Your ideas may not be in alignment with 
the pursuit of happiness...


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

Repeating assertions in regular expression

[candide]

The regular expression HOWTO 
(http://docs.python.org/howto/regex.html#more-metacharacters) explains 
the following


# --
zero-width assertions should never be repeated, because if they match 
once at a given location, they can obviously be matched an infinite 
number of times.

# --


Why the wording is "should never" ? Repeating a zero-width assertion is 
not forbidden, for instance :


>>> import re
>>> re.compile("\\b\\b\w+\\b\\b")
<_sre.SRE_Pattern object at 0xb7831140>
>>>

Nevertheless, the following doesn't execute :

>>> re.compile("\\b{2}\w+\\b\\b")
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/re.py", line 190, in compile
return _compile(pattern, flags)
  File "/usr/lib/python2.7/re.py", line 245, in _compile
raise error, v # invalid expression
sre_constants.error: nothing to repeat
>>>


\\b\\b and \\b{2} aren't equivalent ?


Surprisingly, the engine doesn't optimize repeated boundary assertions, 
for instance


# --
import re
import time

a=time.clock()
len("\\b\\b\\b"*10+"\w+")
b=time.clock()
print "CPU time : %.2f s" %(b - a)

a=time.clock()
re.compile("\\b\\b\\b"*10+"\w+")
b=time.clock()
print "CPU time : %.2f s" %(b - a)
# --

outputs:

# --
CPU time : 0.00 s
CPU time : 1.33 s
# --


Your comments are welcome!
--
http://mail.python.org/mailman/listinfo/python-list

Re: Avoid race condition with Popen.send_signal

[Chris Angelico]

On Tue, Jan 3, 2012 at 7:44 PM, Jérôme  wrote:
> If so, I don't see how I can protect myself from that. Checking the process
> is alive and then hoping that the time interval for the race condition is so
> small that there are few chances for that to happen (because the OS
> quarantines PID numbers for a while, for instance) ?

The probability is extremely small. PIDs are generally allocated
sequentially, and obviously one won't be reallocated until the
previous process has terminated. You're looking at a narrow window of
opportunity between a check and an action; you don't really need to
worry about PID reuse within that window, unless there's a particular
reason to fear it (eg your process is very low priority, or there's a
lot of "process spinning" happening). Under normal circumstances, you
won't see a new process start up with the same PID for some time.

(I can't make a statement on Python's module, though.)

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

Re: Avoid race condition with Popen.send_signal

[Jérôme]

Tue, 3 Jan 2012 19:58:57 +1100
Chris Angelico a écrit:

> On Tue, Jan 3, 2012 at 7:44 PM, Jérôme  wrote:
> > If so, I don't see how I can protect myself from that. Checking the
> > process is alive and then hoping that the time interval for the race
> > condition is so small that there are few chances for that to happen
> > (because the OS quarantines PID numbers for a while, for instance) ?
> 
> The probability is extremely small. PIDs are generally allocated
> sequentially, and obviously one won't be reallocated until the
> previous process has terminated. You're looking at a narrow window of
> opportunity between a check and an action; you don't really need to
> worry about PID reuse within that window, unless there's a particular
> reason to fear it (eg your process is very low priority, or there's a
> lot of "process spinning" happening). Under normal circumstances, you
> won't see a new process start up with the same PID for some time.
> 
> (I can't make a statement on Python's module, though.)

Thanks for clarifying this.

(Out of curiosity, what would be the way to be sure when not in "normal
circumstances" ?)

So I rely on the OS for not allocating a "recently released" PID. However, if
the PID was released long ago, I still need to cover myself up as Popen won't
do it for me.

E.g.:

I have an application that can spawn a subprocess to play a beep. I want it
to kill the subprocess when exiting.

To do so, my close() method must

  a/ Check if any subprocess has actually been launched (I store the Popen in
  a variable called _beep_process. If Popen has not been called, the variable
  is init to 0 and the call to send_signal will fail.)

  b/ Check if the process is still alive using Popen.poll() and returncode
  (otherwise, I might kill a new process)

  c/ Catch the exception in case the process would be dead since the last
  check (otherwise, I might get an error from send_signal)


It looks like this :

#
# Close
#
def _close (self, widget):
# If self._beep_process != 0, a subprocess was launched at some point
if (0 != self._beep_process):
print "process launched"
self._beep_process.poll()
# If process still alive
if (None == self._beep_process.returncode):
print "process stil alive"
# Send signal
try:
self._beep_process.send_signal(signal.SIGINT)
except OSError, e:
if e.errno == errno.ESRCH:
print "process just died"
pass  # process already dead
else:
raise # something else wrong - raise exception
else:
print "signal sent"
# wait for process to complete
self._beep_process.wait()
else:
print "process already dead"
# Close application
Gtk.main_quit()
#

I would have expected something shorter.

For instance, Popen.send_signal() should not be able to send a signal to a
subprocess that has already returned, should it ? Is there any good reason
for allowing it to do so ? If not, it would spare me check b/ in this example.

-- 
Jérôme
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Repeating assertions in regular expression

[Devin Jeanpierre]

> \\b\\b and \\b{2} aren't equivalent ?

This sounds suspiciously like a bug!

> Why the wording is "should never" ? Repeating a zero-width assertion is not
> forbidden, for instance :
>
 import re
 re.compile("\\b\\b\w+\\b\\b")
> <_sre.SRE_Pattern object at 0xb7831140>


I believe this is meant to refer to arbitrary-length repetitions, such
as r'\b*', not simple concatenations like that. r'\b*' will abort the
whole match if is run on a boundary, because Python detects a
repetition of a zero-width match and decides this is an error.


A little OT:

I'm not really sure why Python does it this way. It's possible to
match r'\b*' fairly painlessly: instead of aborting the whole match on
a repeat of nothing, it can backtrack. So what should happen is that
the RE engine looks at \b* and does the following:

Is there one \b?
Yes.
Is there another \b?
Backtrack: You haven't read any more characters since the last match
in the * operation
# The result now is that we've matched '\b*' with exactly one '\b' and
can move on to the rest of the input


This is possible (I haven't tried implementing it, but it's e.g.
mentioned in Russ Cox's regular expression papers), you need to
augment the backtracking search with a notion of the regular
expression having "progress" so that you can require progress at
certain points. Otherwise you obviously get problems with nested stars
and things like that. (As it happens, Python's regex engine can't
handle nested stars either).

I'd be appreciative if anyone who works on re or regex can discuss
this a little.

-- Devin

On Tue, Jan 3, 2012 at 3:46 AM, candide  wrote:
> The regular expression HOWTO
> (http://docs.python.org/howto/regex.html#more-metacharacters) explains the
> following
>
> # --
> zero-width assertions should never be repeated, because if they match once
> at a given location, they can obviously be matched an infinite number of
> times.
> # --
>
>
> Why the wording is "should never" ? Repeating a zero-width assertion is not
> forbidden, for instance :
>
 import re
 re.compile("\\b\\b\w+\\b\\b")
> <_sre.SRE_Pattern object at 0xb7831140>

>
> Nevertheless, the following doesn't execute :
>
 re.compile("\\b{2}\w+\\b\\b")
> Traceback (most recent call last):
>  File "", line 1, in 
>  File "/usr/lib/python2.7/re.py", line 190, in compile
>    return _compile(pattern, flags)
>  File "/usr/lib/python2.7/re.py", line 245, in _compile
>    raise error, v # invalid expression
> sre_constants.error: nothing to repeat

>
>
> \\b\\b and \\b{2} aren't equivalent ?
>
>
> Surprisingly, the engine doesn't optimize repeated boundary assertions, for
> instance
>
> # --
> import re
> import time
>
> a=time.clock()
> len("\\b\\b\\b"*10+"\w+")
> b=time.clock()
> print "CPU time : %.2f s" %(b - a)
>
> a=time.clock()
> re.compile("\\b\\b\\b"*10+"\w+")
> b=time.clock()
> print "CPU time : %.2f s" %(b - a)
> # --
>
> outputs:
>
> # --
> CPU time : 0.00 s
> CPU time : 1.33 s
> # --
>
>
> Your comments are welcome!
> --
> http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: .format vs. %

[Andrew Berg]

On 1/2/2012 11:58 PM, Ian Kelly wrote:
> I can't believe I'm taking Rick's side here, but the docs do say:
> 
> "Note: The formatting operations described here are obsolete and may
> go away in future versions of Python. Use the new String Formatting in
> new code."
> 
> http://docs.python.org/py3k/library/stdtypes.html#old-string-formatting-operations
And that is mainly what I based my statement on. As I said, it's not
likely to be any time soon. I highly doubt it will even become
deprecated in 3.3, but it wouldn't surprise me if it becomes deprecated
in 3.4 and removed in 4.0. In any case, I should've said "will probably
go away".

To add my opinion on it, I find format() much more readable and easier
to understand (with the exception of the {} {} {} {} syntax), and would
love to see %-style formatting phased out.

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

Regular expression : non capturing groups are faster ?

[candide]

Excerpt from the Regular Expression HOWTO 
(http://docs.python.org/howto/regex.html#non-capturing-and-named-groups) :



---
It should be mentioned that there’s no performance difference in 
searching between capturing and non-capturing groups; neither form is 
any faster than the other.

---


Now from the Perl Regular Expression tutorial 
(http://perldoc.perl.org/perlretut.html#Non-capturing-groupings) :



---
Because there is no extraction, non-capturing groupings are faster than 
capturing groupings.

---


The second assertion sounds more likely. It seems very odd that Python 
and Perl implementations are divergent on this point. Any opinion ?



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

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

[Eelco]

On Jan 3, 3:38 am, alex23  wrote:
> On Dec 27 2011, 8:01 pm, Eelco  wrote:
>
> > But I consider it a reasonable change for a
> > 'python 4', or whatever the next major version change will be called.
>
> You do realise there were 8 years between 2 & 3? You might be waiting
> for quite some time.

Yes, I realize this discussion is quite theoretical in nature. Some of
the more 'emotionally engaged' participants might do well to keep that
in mind as well.

> Conversely, you could pitch in behind Rick Johnson's Python 4000 fork,
> I sure it's progressing nicely given how long Rick has been talking it
> up.

Would you be so kind as to leave your personal feuds at the door?

> > Writing a code-conversion tool to convert from *args to args::tuple
> > would be quite easy indeed.
>
> You might want to ask people maintaining libraries in both 2.x & 3.x
> via 2to3 just how well that's working out for them. If the impact of
> changes was trivially obvious, the programming landscape would look
> very different indeed.

Of course if a conversion tool falters on even a single construct,
automated conversion is not going to be reliable, and thats going to
be a pain. But whatever python 4 will be like, its not going to be
backwards compatible by definition; and at least I dont think this
proposed change will contribute to the trouble of conversion between
the two. It is really quite a superficial syntax tweak.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pickling instances of metaclass generated classes

[lars van gemerden]

On Dec 29 2011, 10:55 am, lars van gemerden 
wrote:
> Hello,
>
> Can someone help me with the following:
>
> I am using metaclasses to make classes and these classes to make
> instances. Now I want to use multiprocessing, which needs to pickle
> these instances.
>
> Pickle cannot find the class definitions of the instances. I am trying
> to add a line to the __new__ of the metaclass to add the new class
> under the right name in the right module/place, so pickle can find
> it.
>
> Is this the right approach? Can anyone explain to me where/how to add
> these classes for pickle to find and maybe why?
>
> Thanks in advance,
>
> Lars

Ok,

After reading all posts (thanks a lot), I am considering to use the
following base metaclass for all metaclasses that must lead to
pickleable instances (not pickleable classes):


import sys

class Meta(type):
def __new__(mcls, name, bases, attrs):
cls = type.__new__(mcls, name, bases, attrs)
setattr(sys.modules[__name__], name, cls)
return cls


if __name__ == '__main__':
instance = Meta("Klass", (str,),{})("apple")
s = pickle.dumps(instance)
delattr(sys.modules[__name__], "Klass")
Meta("Klass", (str,),{})
inst = pickle.loads(s)
print instance
print inst
print type(instance) is type(inst)

Can anyone see any drawbacks to this approach? I've also tested the
case where the Meta metaclass is defined in another module.

Cheers, Lars
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: .format vs. %

[Stefan Krah]

Andrew Berg  wrote:
> To add my opinion on it, I find format() much more readable and easier
> to understand (with the exception of the {} {} {} {} syntax), and would
> love to see %-style formatting phased out.

For me the %-style is much more readable. Also, it is significantly
faster:

$ ./python -m timeit -n 100 '"%s" % 7.928137192'
100 loops, best of 3: 0.0164 usec per loop
$ ./python -m timeit -n 100 '"{}".format(7.928137192)'
100 loops, best of 3: 1.01 usec per loop


In the real-world telco benchmark for _decimal, replacing the single line

outfil.write("%s\n" % t)

with

outfil.write("{}\n".format(t))


adds 23% to the runtime. I think %-style formatting should not be
deprecated at all.


Stefan Krah


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

Re: Regular expression : non capturing groups are faster ?

[Devin Jeanpierre]

> The second assertion sounds more likely. It seems very odd that Python and
> Perl implementations are divergent on this point. Any opinion ?

The Python documentation oversimplifies. What it means to say is that
while one might expect capturing matches to do extra work proportional
to the capture, they do not. They don't do anything other than mark
down where to extract submatches, and the extra work done is pretty
much negligible. (That is, the work done for submatch extraction is a
polynomial (looks like quadratic) in the number of capturing groups
(which is very small almost always), with a small coefficient).

The Perl documentation is technically correct, but if the HOWTO said
it, it would give the wrong impression. You shouldn't care about
capturing vs noncapturing except with regards to how it interferes
with your group numbering scheme.

-- Devin

On Tue, Jan 3, 2012 at 6:14 AM, candide  wrote:
> Excerpt from the Regular Expression HOWTO
> (http://docs.python.org/howto/regex.html#non-capturing-and-named-groups) :
>
>
> ---
> It should be mentioned that there’s no performance difference in searching
> between capturing and non-capturing groups; neither form is any faster than
> the other.
> ---
>
>
> Now from the Perl Regular Expression tutorial
> (http://perldoc.perl.org/perlretut.html#Non-capturing-groupings) :
>
>
> ---
> Because there is no extraction, non-capturing groupings are faster than
> capturing groupings.
> ---
>
>
> The second assertion sounds more likely. It seems very odd that Python and
> Perl implementations are divergent on this point. Any opinion ?
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Regular expression : non capturing groups are faster ?

[Octavian Rasnita]

From: "candide" 
Subject: Regular expression : non capturing groups are faster ?


Excerpt from the Regular Expression HOWTO 
(http://docs.python.org/howto/regex.html#non-capturing-and-named-groups) :


---
It should be mentioned that there’s no performance difference in 
searching between capturing and non-capturing groups; neither form is 
any faster than the other.
---


Now from the Perl Regular Expression tutorial 
(http://perldoc.perl.org/perlretut.html#Non-capturing-groupings) :


---
Because there is no extraction, non-capturing groupings are faster than 
capturing groupings.
---


The second assertion sounds more likely. It seems very odd that Python 
and Perl implementations are divergent on this point. Any opinion ?


-- 
**
At least in Perl's case, it is true. I tested and using (?:...) is much faster 
than ().

Of course, it takes a few seconds for dozen million matches...

Octavian


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

Re: Avoid race condition with Popen.send_signal

[Heiko Wundram]

Am 03.01.2012 02:19, schrieb Adam Skutt:

On Jan 2, 6:09 pm, Jérôme  wrote:

What is the clean way to avoid this race condition ?


The fundamental race condition cannot be removed nor avoided. Ideally,
avoid the need to send the subprocess a signal in the first place.  If
it cannot be avoided, then trap the exception.


Yes, it can be avoided, that's what the default SIGCHLD-handling 
(keeping the process as a zombie until it's explicitly collected by a 
wait*()) is for, which forces the PID not to be reused by the operating 
system until the parent has acknowledged (by actively calling wait*()) 
that the child has terminated.


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

Re: Python education survey

[Eelco]

> Why do people use pretty when we already have words that carry more
> specific meaning? Because they are lazy! And laziness begets
> stupidity.

No, that would be because they are not autistic. Most people like
having a repertoire of words with subtly different meanings in their
natural language, because there is a demand for this semantic richness.
-- 
http://mail.python.org/mailman/listinfo/python-list

Locale bug?

[Marko Rauhamaa]

Mysterious 8-bit characters appear in the string returned by strftime.

$ python
Python 2.7.2 (default, Oct 27 2011, 01:36:46) 
[GCC 4.6.1 20111003 (Red Hat 4.6.1-10)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import time, locale
>>> locale.setlocale(locale.LC_TIME, ('fi_FI', 'UTF-8'))
'fi_FI.UTF-8'
>>> time.strftime("%a, %d %b %Y %H:%M:%S %z (%Z)")
'ti, 03 tammi\xc2\xa0 2012 14:52:47 +0200 (EET)'
>>> 
$ python3
Python 3.2.1 (default, Jul 11 2011, 18:55:33) 
[GCC 4.6.1 20110627 (Red Hat 4.6.1-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import time, locale
>>> locale.setlocale(locale.LC_TIME, ('fi_FI', 'UTF-8'))
'fi_FI.UTF-8'
>>> time.strftime("%a, %d %b %Y %H:%M:%S %z (%Z)")
'ti, 03 tammi\xa0 2012 14:51:57 +0200 (EET)'
>>> 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: .format vs. %

[Chris Angelico]

On Tue, Jan 3, 2012 at 10:47 PM, Stefan Krah  wrote:
> For me the %-style is much more readable.

It's also very similar to C's printf, which means it's similar to
everything else that's similar to printf. That makes it instantly
grokkable to many many people, which is a Good Thing. It's like using
the + operator for string concatenation - there's no requirement to do
so, and not all languages do (REXX, PHP, and SQL come to mind); but
supporting the "obvious thing" gives a huge slab of potential Python
users the chance to understand and write code with one less trip to
the documentation.

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

Re: Spamming PyPI with stupid packages

[Ethan Furman]

Peter Otten wrote:

Lie Ryan wrote:


On 01/02/2012 11:20 PM, Peter Otten wrote:

Felinx Lee wrote:


I have removed those packages (girlfriend and others) from PyPI forever,
I apologize for that.

The thought police has won :(

I think the community has a right to defend themselves against trolls.
If it's just bad naming, we can probably just laugh it off; but when a
failed joke spans a half dozen module and just opens a browser to his
website, there is no value for it to stay at PyPI. Additionally, it may
fuel copycats: http://pypi.python.org/pypi/kimwoohyeon1/1.3.0 (do anyone
have any idea who submitted that one?)


I think it's a judgment call.

"maybe policing uploads is worse than cluttering PyPI's disk space and RSS 
feed with dumb 1 KB packages." (Matt Chaput)


I'd drop the "maybe".


It's hard enough finding what one wants without having to wade through 
crap.  PyPI is not the place for it.


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

Re: Avoid race condition with Popen.send_signal

[Adam Skutt]

On Jan 3, 7:31 am, Heiko Wundram  wrote:
> Am 03.01.2012 02:19, schrieb Adam Skutt:
>
> > On Jan 2, 6:09 pm, Jérôme  wrote:
> >> What is the clean way to avoid this race condition ?
>
> > The fundamental race condition cannot be removed nor avoided. Ideally,
> > avoid the need to send the subprocess a signal in the first place.  If
> > it cannot be avoided, then trap the exception.
>
> Yes, it can be avoided, that's what the default SIGCHLD-handling
> (keeping the process as a zombie until it's explicitly collected by a
> wait*()) is for, which forces the PID not to be reused by the operating
> system until the parent has acknowledged (by actively calling wait*())
> that the child has terminated.

No, you still can see ESRCH when sending signals to a zombie process.
Code that sends signals to child processes via kill(2) must be
prepared for the call to fail at anytime since the process can die at
anytime.  It can't handle the signal, so it's treated as if it doesn't
exist by kill(2) in this case.  However, you don't have to worry about
sending the signal to the wrong process.

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

Re: .format vs. %

[Ethan Furman]

Ian Kelly wrote:

I'm not sure it's true that "there are no plans to do so in the
foreseeable future."  According to the release notes from Python 3.0,
% formatting was supposed to be deprecated in Python 3.1.


Eric Smith wrote (from a thread on pydev in 02-2011):
> The last thread on this I have a reference to was in September 2009. I
> think was basically the outcome:
> http://mail.python.org/pipermail/python-dev/2009-September/092399.html
>
> So there will be no deprecation, just a gradual shift to PEP 3101
> formatting.

Ian Kelly wrote:

Maybe there was a discussion on py-dev
where it was decided that % formatting would not be deprecated after
all (in which case the misleading "obsolete" note really ought to be
removed from the documentation).  


Agreed that this is a documentation bug.

Ian Kelly wrote:

The reason for deprecating it is because Python currently has no fewer
than three mechanisms for string formatting (not even including
ordinary string concatenation), which according to the Zen of Python
is two too many.


"one obvious way" != "only one way"

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

Re: Avoid race condition with Popen.send_signal

[Heiko Wundram]

Am 03.01.2012 14:40, schrieb Adam Skutt:

On Jan 3, 7:31 am, Heiko Wundram  wrote:

Yes, it can be avoided, that's what the default SIGCHLD-handling
(keeping the process as a zombie until it's explicitly collected by a
wait*()) is for, which forces the PID not to be reused by the operating
system until the parent has acknowledged (by actively calling wait*())
that the child has terminated.


No, you still can see ESRCH when sending signals to a zombie process.
Code that sends signals to child processes via kill(2) must be
prepared for the call to fail at anytime since the process can die at
anytime.  It can't handle the signal, so it's treated as if it doesn't
exist by kill(2) in this case.  However, you don't have to worry about
sending the signal to the wrong process.


Getting an error on kill (which you can catch) is not about the race 
that the posters were speculating about (i.e., sending the signal to the 
wrong process), and that's what I was trying to put straight. The only 
advice that I wanted to give is:


1) before calling wait to collect the child, call kill as much as you 
like, and in case it errors, ignore that,


2) after calling wait, never, ever kill, and you don't need to, because 
you already know the process is gone.


There's no race possibility in this, _except_ if you alter handling of 
SIGCHLD away from the default (i.e., to autocollect children), in which 
case you have the possibility of a race and shooting down unrelated 
processes (which the discussion was about).


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

Re: .format vs. %

[Neil Cerutti]

On 2012-01-03, Stefan Krah  wrote:
> Andrew Berg  wrote:
>> To add my opinion on it, I find format() much more readable and easier
>> to understand (with the exception of the {} {} {} {} syntax), and would
>> love to see %-style formatting phased out.
>
> For me the %-style is much more readable. Also, it is significantly
> faster:
>
> $ ./python -m timeit -n 100 '"%s" % 7.928137192'
> 100 loops, best of 3: 0.0164 usec per loop
> $ ./python -m timeit -n 100 '"{}".format(7.928137192)'
> 100 loops, best of 3: 1.01 usec per loop
>
> In the real-world telco benchmark for _decimal, replacing the
> single line
>
> outfil.write("%s\n" % t)
>
> with
>
> outfil.write("{}\n".format(t))
>
> adds 23% to the runtime. I think %-style formatting should not
> be deprecated at all.
   
When it becomes necessary, it's possible to optimize it by
hoisting out the name lookups.
   ...
   outfil_write = outfil.write
   append_newline = "{}\n".format
   ...
   outfil_write(append_newline(t))
   ...

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

Re: Locale bug?

[=?ISO-8859-1?Q?Trond_Endrest=F8l?=]

Marko Rauhamaa  writes:

> Mysterious 8-bit characters appear in the string returned by strftime.
>
> $ python
> Python 2.7.2 (default, Oct 27 2011, 01:36:46) 
> [GCC 4.6.1 20111003 (Red Hat 4.6.1-10)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import time, locale
> >>> locale.setlocale(locale.LC_TIME, ('fi_FI', 'UTF-8'))
> 'fi_FI.UTF-8'
> >>> time.strftime("%a, %d %b %Y %H:%M:%S %z (%Z)")
> 'ti, 03 tammi\xc2\xa0 2012 14:52:47 +0200 (EET)'
> >>> 
> $ python3
> Python 3.2.1 (default, Jul 11 2011, 18:55:33) 
> [GCC 4.6.1 20110627 (Red Hat 4.6.1-1)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import time, locale
> >>> locale.setlocale(locale.LC_TIME, ('fi_FI', 'UTF-8'))
> 'fi_FI.UTF-8'
> >>> time.strftime("%a, %d %b %Y %H:%M:%S %z (%Z)")
> 'ti, 03 tammi\xa0 2012 14:51:57 +0200 (EET)'
> >>> 

It may be OS-specific. Your sample code runs fine on FreeBSD/i386
8.2-STABLE. The OS and Python 2.7.2 & 3.2.2 were recently compiled and
installed on my system.

trond@enterprise:~>uname -sr
FreeBSD 8.2-STABLE
trond@enterprise:~>python
Python 2.7.2 (default, Dec 20 2011, 08:49:23)
[GCC 4.2.2 20070831 prerelease [FreeBSD]] on freebsd8
Type "help", "copyright", "credits" or "license" for more information.
>>> import time, locale
>>> locale.setlocale(locale.LC_TIME, ('fi_FI', 'UTF-8'))
'fi_FI.UTF-8'
>>> time.strftime("%a, %d %b %Y %H:%M:%S %z (%Z)")
'Ti, 03 Tam 2012 15:02:32 +0100 (CET)'
>>>
trond@enterprise:~>python3.2
Python 3.2.2 (default, Dec 21 2011, 14:42:29)
[GCC 4.2.2 20070831 prerelease [FreeBSD]] on freebsd8
Type "help", "copyright", "credits" or "license" for more information.
>>> import time, locale
>>> locale.setlocale(locale.LC_TIME, ('fi_FI', 'UTF-8'))
'fi_FI.UTF-8'
>>> time.strftime("%a, %d %b %Y %H:%M:%S %z (%Z)")
'Ti, 03 Tam 2012 15:03:15 +0100 (CET)'
>>>
trond@enterprise:~>

-- 
--
Trond Endrestøl
ACM, NAS, NUUG, SAGE, USENIX
-- 
http://mail.python.org/mailman/listinfo/python-list

Parse multi line with re module.

[Ganesh Kumar]

Hi Guys,

I want parse multiple line. with re.module, this is my given string
http://dpaste.com/680760/ I have try with re.compile module. I want parse
two line mac address and channel,
I have done with for mac address finding

r = re.compile("^Searching for OPUSH on (\w\w(:\w\w)+)")

for channel finding

device_r = re.compile("^Channel: (\d+)")

the two parsing string working. but I want combine two pattern in to one.

This is my code
http://www.bpaste.net/show/21323/

please guide me .


-Ganesh

Did I learn something today? If not, I wasted it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: .format vs. %

[Stefan Krah]

Neil Cerutti  wrote:
> > In the real-world telco benchmark for _decimal, replacing the
> > single line
> >
> > outfil.write("%s\n" % t)
> >
> > with
> >
> > outfil.write("{}\n".format(t))
> >
> > adds 23% to the runtime. I think %-style formatting should not
> > be deprecated at all.
>
> When it becomes necessary, it's possible to optimize it by
> hoisting out the name lookups.
>...
>outfil_write = outfil.write
>append_newline = "{}\n".format
>...
>outfil_write(append_newline(t))
>...

Did you profile this? I did, and it still adds 22% to the runtime.


Stefan Krah


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

Re: Avoid race condition with Popen.send_signal

[Adam Skutt]

On Jan 3, 3:44 am, Jérôme  wrote:
> Mon, 2 Jan 2012 19:16:50 -0800 (PST)
> Adam Skutt a écrit:
>
> > No. It is possible (however unlikely) for EPERM to be legitimately
> > returned in this case.  Anything other than EINVAL should be
> > interpreted as "The child process is dead".  Hence why you should
> > avoid sending the signal in the first place: the situations where you
> > don't run the risk of possibly killing an innocent bystander are
> > pretty narrow.  While unlikely on modern UNiX and Linux, IMO it's best
> > to avoid the issue altogether whenever possible.
>
> Should I understand that Popen.send_signal blindly sends the signal to the
> process of PID Popen.pid, and therefore could kill a new process of the same
> PID that would have been launched by the same user in another program ?
>

Or possibly one launched by another user altogether.  By /default/,
child processes that terminate become zombies and remain in that state
until their parent reaps them via wait(2) or a related syscall.  This
means that until you make such a call, the signal is delivered to the
desired child process.  In this case, kill(2) still returns ESRCH
since the child process is a zombie and cannot possibly respond to the
signal.

However, if SIGCHLD has been explicitly ignored or has no SA_NOCLDWAIT
set, child processes are reaped automatically.  Likewise, it is
possible to install a signal handler for SIGCHLD that calls wait and
reaps the child processes.  Do you know what all of your other Python
modules and extensions do? If so, then you can probably rely on the
default semantics.  If not, I'd strongly suggest a more conservative
approach.

Regardless, of whether you can rely on the presence of your zombie
children or not, you should expect the kill(2) call to fail and be
prepared to trap the failure.

Obviously, all of this is rather UNIX / Linux specific.

> If so, I don't see how I can protect myself from that. Checking the process
> is alive and then hoping that the time interval for the race condition is so
> small that there are few chances for that to happen (because the OS
> quarantines PID numbers for a while, for instance) ?

The conservative approach is to use another IPC mechanism to talk to
the process, such as a pipe or a socket.  Why are you trying to send
the child process SIGINT in the first place?

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

Re: Avoid race condition with Popen.send_signal

[Adam Skutt]

On Jan 3, 3:58 am, Chris Angelico  wrote:
> On Tue, Jan 3, 2012 at 7:44 PM, Jérôme  wrote:
> > If so, I don't see how I can protect myself from that. Checking the process
> > is alive and then hoping that the time interval for the race condition is so
> > small that there are few chances for that to happen (because the OS
> > quarantines PID numbers for a while, for instance) ?
>
> The probability is extremely small. PIDs are generally allocated
> sequentially, and obviously one won't be reallocated until the
> previous process has terminated. You're looking at a narrow window of
> opportunity between a check and an action; you don't really need to
> worry about PID reuse within that window, unless there's a particular
> reason to fear it (eg your process is very low priority, or there's a
> lot of "process spinning" happening). Under normal circumstances, you
> won't see a new process start up with the same PID for some time.
>

Not all operating systems attempt to generate sequential processes
IDs.  The window can be rather large in certain situations, and if you
cannot rely on your child processes becoming zombies and kill being
called only when the child is alive or a zombie, then you should not
be calling kill(2) at all.  Killing an unrelated process will be
considered as a bug by users.  Hence why I find it easier just to
avoid the problem altogether if I can.

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

Re: Regular expression : non capturing groups are faster ?

[candide]

Le 03/01/2012 12:56, Devin Jeanpierre a écrit :

The second assertion sounds more likely. It seems very odd that Python and
Perl implementations are divergent on this point. Any opinion ?


The Python documentation oversimplifies.


You meant Perl Documentation, didn't you ?


It's a commun opinion that non-capturing groups have a price (minor), 
for instance Jan Goyvaerts, a well known regular expression guru, 
refering to Python code, tells :



non-capturing groups (...)  offer (slightly) better performance as the 
regex engine doesn't have to keep track of the text matched by 
non-capturing groups.



[link is there : 
http://stackoverflow.com/questions/2703029/why-regular-expressions-non-capturing-group-is-not-working]




It seems Javascript performs better respect to non-capturing groups : 
http://jsperf.com/regex-capture-vs-non-capture


The same for java : http://eyalsch.wordpress.com/2009/05/21/regex/
(no benchmarks).

For my part, Python tests didn't show any kind of significative penality.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Avoid race condition with Popen.send_signal

[Jérôme]

Tue, 3 Jan 2012 06:12:59 -0800 (PST)
Adam Skutt a écrit:

> The conservative approach is to use another IPC mechanism to talk to
> the process, such as a pipe or a socket.  Why are you trying to send
> the child process SIGINT in the first place?

Say, you've got an application that plays a sound for a few seconds, using an
external program for that (beep, sox). If you close the application, you want
the sound to stop as well.

I don't know much about subprocess, not much more than what is in the
tutorial : http://docs.python.org/library/subprocess.html

(I don't know much about signalling either, I'm learning...)

I naively thought kill() was the "normal" way. Then realized terminate() or
even send_signal(SIGINT) would be softer.

What would be a good approach, then ?

Should I try something like this ?

communicate(input="Ctrl+C")

(I'd need to figure out how to write Ctrl+C...)

Would that be cross-platform ?

-- 
Jérôme
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Avoid race condition with Popen.send_signal

[Adam Skutt]

On Jan 2, 11:53 pm, Cameron Simpson  wrote:
> On 02Jan2012 19:16, Adam Skutt  wrote:
> | On Jan 2, 8:44 pm, Cameron Simpson  wrote:
> | > On 02Jan2012 20:31, Devin Jeanpierre  wrote:
> | > | > I think that catching the exception is probably the most Pythonic way.
> | > |
> | > | It's the only correct way.
> | >
> | > Indeed, but be precise - chek that it _is_ error 3, or more portably,
> | > errno.ESRCH. POSIX probably mandates that that is a 3, but the symbol
> | > should track the local system if it differs. Example:
> |
> | No. It is possible (however unlikely) for EPERM to be legitimately
> | returned in this case.  Anything other than EINVAL should be
> | interpreted as "The child process is dead".
>
> Sure. I was more taking the line: catch and accept only the specific
> errors you understand.

That advice really only applies when we have interfaces that don't
fully define their exceptional conditions.  That's not the case here.
Though I should correct myself and note that EPERM can only occur if
SIGCHLD is being handled in a non-default fashion.  That being said,
I'm not sure any error code should be treated differently from another
here.

> Of course he can catch EPERM also. But any other
> variant should at the least generate a warning to stderr or a log
> it is _unexpected_.

Are they really unexpected though?  Even if they are, what is logging
an error going to gain anyone?  Even crashing may not be helpful,
especially given that there have been bugs in the past with the return
codes from kill(2).  Certainly, I'd be far more concerned about
ensuring my code doesn't accidentally kill the wrong process than
worrying about ensuring it handles the return code from kill(2)
correctly.

> I take your point that reraising the exception may be overkill for
> failed signal delivery (if that was your point). But I am arguing for
> being very careful about what you silently pass as an ok thing.
>

Trapping too few conditions is just as erroneous as trapping too
many.  This is especially true when dealing with UNIX system calls.
The right behavior is frequently not as simple as it may appear,
unfortunately.

> | Hence why you should
> | avoid sending the signal in the first place: the situations where you
> | don't run the risk of possibly killing an innocent bystander are
> | pretty narrow.  While unlikely on modern UNiX and Linux, IMO it's best
> | to avoid the issue altogether whenever possible.
>
> Fair enough too. But sometimes you need to nail a rogue child.

Even if I believed that were true, I wouldn't use SIGINT to do it.

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

Re: .format vs. %

[Neil Cerutti]

On 2012-01-03, Stefan Krah  wrote:
> Neil Cerutti  wrote:
>> > In the real-world telco benchmark for _decimal, replacing the
>> > single line
>> >
>> > outfil.write("%s\n" % t)
>> >
>> > with
>> >
>> > outfil.write("{}\n".format(t))
>> >
>> > adds 23% to the runtime. I think %-style formatting should not
>> > be deprecated at all.
>>
>> When it becomes necessary, it's possible to optimize it by
>> hoisting out the name lookups.
>>...
>>outfil_write = outfil.write
>>append_newline = "{}\n".format
>>...
>>outfil_write(append_newline(t))
>>...
>
> Did you profile this? I did, and it still adds 22% to the runtime.

No, I did not. And that's disappointing.

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

Re: Can't write to a directory made w/ os.makedirs

[David Goldsmith]

On Jan 1, 7:43 pm, MRAB  wrote:
> On 02/01/2012 03:14, David Goldsmith wrote:
>
>
>
>
>
>
>
>
>
> > On Jan 1, 7:05 am, Tim Golden  wrote:
> >>  On 01/01/2012 12:05, David Goldsmith wrote:
> >>    >>  ie can the Python process creating the directories,
>
> >>    >  Yes.
>
> >>    >>  and a subprocess called from it create a simple file?
>
> >>    >  No.
>
> >>    >>  Depending on where you are in the filesystem, it may indeed
> >>    >>  be necessary to be running as administrator. But don't try
> >>    >>  to crack every security nut with an elevated sledgehammer.
>
> >>    >  If you mean running as admin., those were my sentiments exactly.  So,
> >>    >  there isn't something specific I should be doing to assure that my
> >>    >  subproceses can write to directories?
>
> >>  In the general case, no. By default, a subprocess will have
> >>  the same security context as its parent. The exception is
> >>  where the parent (the Python processing invoking subprocess.call
> >>  in this example) is already impersonating a different user;
> >>  in that case, the subprocess will inherit its grandparent's
> >>  context.
>
> >>  But unless you're doing something very deliberate here then
> >>  I doubt if that's biting you.
>
> >>  Can I ask: are you absolutely certain that the processes
> >>  you're calling are doing what you think they are and failing
> >>  where you think they're failing?
>
> >>  TJG
>
> > I'm a mathematician: the only thing I'm absolutely certain of is
> > nothing.
>
> > Here's my script, in case that helps:
>
> > import os
> > import sys
> > import stat
> > import os.path as op
> > import subprocess as sub
> > from os import remove
> > from os import listdir as ls
> > from os import makedirs as mkdir
>
> > def doFlac2Mp3(arg, d, fl):
> >      if '.flac' in [f[-5:] for f in fl]:
> >          newD = d.replace('FLACS', 'MP3s')
> >          mkdir(newD)
> >          for f in fl:
> >              if f[-5:]=='.flac':
> >                  root = f.replace('.flac', '')
> >                  cmd = ['"C:\\Program Files (x86)\\aTunes\\win_tools\
> > \flac.exe" -d ' +
> >                         '--output-prefix=' + newD + '\\', f]
> >                  res = sub.call(cmd)#, env={'PATH': os.defpath})
> >                  if not res:
> >                      cmd = ['"C:\\Program Files (x86)\\aTunes\\win_tools
> > \\lame.exe" -h',
> >                              newD + root + '.wav',  newD + root +
> > '.mp3']
> >                      res = sub.call(cmd)#, env={'PATH': os.defpath})
> >                      if not res:
> >                          rf = newD + root + '.wav'
> >                          remove(rf)
>
> > top=sys.argv[1]
> > op.walk(top, doFlac2Mp3, None)
>
> I think that if the command line should be something like:
>
> "C:\Program Files (x86)\aTunes\win_tools\flac.exe" -d
> --output-prefix=FOO\ BAR
>
> then the cmd should be something like:
>
> cmd = ['C:\\Program Files (x86)\\aTunes\\win_tools\\flac.exe', '-d',
> '--output-prefix="' + newD + '\\"', f]

Thanks again all!  MRAB: your advice was sufficient to get me over the
hump, so to speak, thanks for chiming in!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] Parse multi line with re module.

[Joel Goldstick]

On Tue, Jan 3, 2012 at 9:13 AM, Ganesh Kumar  wrote:
> Hi Guys,
>
> I want parse multiple line. with re.module, this is my given string
> http://dpaste.com/680760/ I have try with re.compile module. I want parse
> two line mac address and channel,
> I have done with for mac address finding
>
> r = re.compile("^Searching for OPUSH on (\w\w(:\w\w)+)")
>
> for channel finding
>
> device_r = re.compile("^Channel: (\d+)")
>
> the two parsing string working. but I want combine two pattern in to one.
>
> This is my code
> http://www.bpaste.net/show/21323/
>
> please guide me .
>
>
> -Ganesh
>
> Did I learn something today? If not, I wasted it.
>
> ___
> Tutor maillist  -  tu...@python.org
> To unsubscribe or change subscription options:
> http://mail.python.org/mailman/listinfo/tutor
>



-- 


Do you know about str.startswith()
http://docs.python.org/library/stdtypes.html#str.startswith

Since your data is so well defined I think it would be simpler to just
read each line, strip whitespace, use startswith() to check for
"Searching for OPUSH on" and "Channel:"

You can slice to pull out the mac address and the channel number like so:

>>> s = "Searching for OPUSH on 00:1D:FD:06:99:99"
>>> s[23:]
'00:1D:FD:06:99:99'   # this will work if no other text follows the mac address
>>> s[23:41]
'00:1D:FD:06:99:99' # this will work to just capture the mac address
>>>

For the Channel number, after stripping whitespace, take the slice from s[9:]

Searching for OPUSH on 00:1D:FD:06:99:99 ...
Channel: 9

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

Re: Avoid race condition with Popen.send_signal

[Adam Skutt]

On Jan 3, 4:38 am, Jérôme  wrote:
> I have an application that can spawn a subprocess to play a beep. I want it
> to kill the subprocess when exiting.

Why?  You shouldn't need to send a signal to tell the process to
terminate: it should terminate when its stdin is closed or when it's
done playing the beep in the first place.  If it doesn't, I would find
a better way to play a beep in the first place.  What you're
attempting to do sounds superfluous and unnecessary.

The only thing you ought to need to do is ensure that the child
process is properly reaped if it terminates before your process
terminates.

> To do so, my close() method must
>
>   a/ Check if any subprocess has actually been launched (I store the Popen in
>   a variable called _beep_process. If Popen has not been called, the variable
>   is init to 0 and the call to send_signal will fail.)
>
>   b/ Check if the process is still alive using Popen.poll() and returncode
>   (otherwise, I might kill a new process)
>
>   c/ Catch the exception in case the process would be dead since the last
>   check (otherwise, I might get an error from send_signal)
>

Steps a and c are all that are necessary under standard SIGCHLD
handling.  However, all of this should be entirely unnecessary in the
first place.  Plus, I have a hard time imagining why something like
'gtk.gdk.beep()' isn't adequate for your needs anyway.

> For instance, Popen.send_signal() should not be able to send a signal to a
> subprocess that has already returned, should it ? Is there any good reason
> for allowing it to do so ? If not, it would spare me check b/ in this example.
>

The problem is being able to distinguish "process is a zombie" from
"process doesn't exist" which both return ESRCH.  This is certainly
possible with careful coding but I'm not sure I would bother except in
the simplest programs.  Too many libraries do too many questionable
things with signal handlers so I find it much safer and easier just to
avoid the damn things whenever possible.

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

Re: .format vs. %

[Neil Cerutti]

On 2012-01-03, Neil Cerutti  wrote:
> On 2012-01-03, Stefan Krah  wrote:
>> Neil Cerutti  wrote:
>>> > In the real-world telco benchmark for _decimal, replacing the
>>> > single line
>>> >
>>> > outfil.write("%s\n" % t)
>>> >
>>> > with
>>> >
>>> > outfil.write("{}\n".format(t))
>>> >
>>> > adds 23% to the runtime. I think %-style formatting should not
>>> > be deprecated at all.
>>>
>>> When it becomes necessary, it's possible to optimize it by
>>> hoisting out the name lookups.
>>>...
>>>outfil_write = outfil.write
>>>append_newline = "{}\n".format
>>>...
>>>outfil_write(append_newline(t))
>>>...
>>
>> Did you profile this? I did, and it still adds 22% to the runtime.
>
> No, I did not. And that's disappointing.

On many levels. Thanks for the correction.

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

Re: .format vs. %

[88888 Dihedral]

davidfx於 2012年1月1日星期日UTC+8上午2時19分34秒寫道：
> Hello everyone,
> I just have a quick question about .format and %r %s %d.  
> 
> Should we always be using .format() for formatting strings or %?
> 
> Example a = 'apples'
>   print "I love {0}.".format(a)
> 
> If I wanted to put .format into a variable, how would I do that.
> 
> Thanks for your information in advance.
> 
> David

This is a good evolution in Python. It is 2012 now and the text I/O part 
is not as important as 10 years ago. The next move of Python could
be easy integration of C++ libraries.

The auto code generation part for low-paid tedious   GUI tasks  is still missing
in the standard Python. 

Boa and wxpython are still not good enough. 

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

Re: Avoid race condition with Popen.send_signal

[Jérôme]

Tue, 3 Jan 2012 07:03:08 -0800 (PST)
Adam Skutt a écrit:

> On Jan 3, 4:38 am, Jérôme  wrote:
> > I have an application that can spawn a subprocess to play a beep. I want
> > it to kill the subprocess when exiting.
> 
> Why?  You shouldn't need to send a signal to tell the process to
> terminate: it should terminate when its stdin is closed or when it's
> done playing the beep in the first place.  If it doesn't, I would find
> a better way to play a beep in the first place.  What you're
> attempting to do sounds superfluous and unnecessary.

Probably. And somehow, I'd be glad.

Once the command (say beep) is called, it does terminate when done with the
beep. I just don't know if it can be stopped while playing and how.

(Perhaps the only clean way would be to call it several times by period of
10ms, for instance, to be able to stop at any time. But this makes the whole
thing much more complicated.)

> The only thing you ought to need to do is ensure that the child
> process is properly reaped if it terminates before your process
> terminates.

The application polls the ongoing child process until it has terminated, and
fetches its returncode. I hope this is "proper reaping".

The tutorial (http://docs.python.org/library/subprocess.html) didn't suggest
me to do anything more than that.
 
> Steps a and c are all that are necessary under standard SIGCHLD
> handling.  However, all of this should be entirely unnecessary in the
> first place.  

That's good news, because it seems a little bit ugly.

> Plus, I have a hard time imagining why something like 'gtk.gdk.beep()'
> isn't adequate for your needs anyway.

Short answer : I may well be, I just didn't know it.

I just looked at it quickly and it does not seem as flexible. Besides, beep
is just an example, I also use sox. And anyway, the whole thing is just a
training exercise I'm inflicting on myself, so I'm interested in solving the
subprocess issue for itself.

> The problem is being able to distinguish "process is a zombie" from
> "process doesn't exist" which both return ESRCH.  This is certainly
> possible with careful coding but I'm not sure I would bother except in
> the simplest programs.  Too many libraries do too many questionable
> things with signal handlers so I find it much safer and easier just to
> avoid the damn things whenever possible.

My small program _seems to_ work with the dirty hacks I already exposed. Yet,
I'd rather stay on the safe and easy side, especially in a future bigger
program. Therefore, I'm still interested in a better way to proceed.

Is there another way to tell beep (or sox) to stop before the end of the
beep ?

AFAIK, the only way to stop it on console is to feed it Ctrl+C. Should I use
communicate() for that ? How ? Apparently, the following does not work :

process.communicate("\C-c")

It may well be that the dirtyness of my program comes from the choice of
external applications that don't allow nice termination through stdin. Or
perhaps is it possible and I haven't figured out how yet...

-- 
Jérôme
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Avoid race condition with Popen.send_signal

[Jérôme]

Tue, 3 Jan 2012 17:24:44 +0100
Jérôme a écrit:

> > Too many libraries do too many questionable things with signal handlers
> > so I find it much safer and easier just to avoid the damn things whenever
> > possible.
> 
> My small program _seems to_ work with the dirty hacks I already exposed.
> Yet, I'd rather stay on the safe and easy side, especially in a future
> bigger program. Therefore, I'm still interested in a better way to proceed.
> 
> Is there another way to tell beep (or sox) to stop before the end of the
> beep ?
> 
> AFAIK, the only way to stop it on console is to feed it Ctrl+C. Should I use
> communicate() for that ? How ? Apparently, the following does not work :
> 
>   process.communicate("\C-c")
> 

I've been reading more and what I wrote now appears to me as silly, as
Ctrl+C, as I understand, is just a way to send SIGINT...

I guess I'll have to do with the signal handling, then.

But I think I'm beggining to understand what you (Adam Skutt) meant. This is
just as dirty as using Ctrl+C to stop beep when using the console, as opposed
to using a software that would wait for a specific keypress to stop (in which
case I could use communicate()).

-- 
Jérôme
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] Parse multi line with re module.

[Robert Sjoblom]

On 3 January 2012 16:21, Joel Goldstick  wrote:
> --

Joel, when you start your emails with this (two dashes) some email
readers (gmail among them) will think you're ending your email; I have
to expand your post because it thinks that what is hidden is the
signature. Just thought you should know.


-- 
best regards,
Robert S.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: MOST COMMON QUESTIONS ASKED BY NON-MUSLIMS ?????????

[John Ladasky]

On Jan 3, 7:40 am, BV  wrote:
> MOST COMMON QUESTIONS ASKED BY NON-MUSLIMS

Q0. Why do thousand-line religious posts appear in comp.lang.python?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pickling instances of metaclass generated classes

[Ian Kelly]

> Ok,
>
> After reading all posts (thanks a lot), I am considering to use the
> following base metaclass for all metaclasses that must lead to
> pickleable instances (not pickleable classes):
>
>
> import sys
>
> class Meta(type):
>def __new__(mcls, name, bases, attrs):
>cls = type.__new__(mcls, name, bases, attrs)
>setattr(sys.modules[__name__], name, cls)
>return cls
>
>
> if __name__ == '__main__':
>instance = Meta("Klass", (str,),{})("apple")
>s = pickle.dumps(instance)
>delattr(sys.modules[__name__], "Klass")
>Meta("Klass", (str,),{})
>inst = pickle.loads(s)
>print instance
>print inst
>print type(instance) is type(inst)
>
> Can anyone see any drawbacks to this approach? I've also tested the
> case where the Meta metaclass is defined in another module.

With this approach you'll need to be conscious of what names you allow for
classes. If you create any classes named "Meta" or "sys", or that shadow
any of the builtins, things could break. For that reason I think the
__reduce__ approach is cleaner (plus it works with the pickle system
instead of trying to fool it, so it may be more robust ib the long term),
but it's your project.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Avoid race condition with Popen.send_signal

[Adam Skutt]

On Jan 3, 10:09 am, Jérôme  wrote:
> Tue, 3 Jan 2012 06:12:59 -0800 (PST)
> Adam Skutt a écrit:
>
> > The conservative approach is to use another IPC mechanism to talk to
> > the process, such as a pipe or a socket.  Why are you trying to send
> > the child process SIGINT in the first place?
>
> Say, you've got an application that plays a sound for a few seconds, using an
> external program for that (beep, sox). If you close the application, you want
> the sound to stop as well.

If your application wants to play audio and terminate playing audio
early, it really should use an audio library and play the sound
directly.  Especially if you're playing so many sounds in such a
fashion you need to terminate them.  If you're playing a single beep
or short sound, then who really cares if it occurs slightly after your
processes ends?  GStreamer is one such library for sound processing
though it may be more complicated than you need.

> Should I try something like this ?
>
>         communicate(input="Ctrl+C")
>
> (I'd need to figure out how to write Ctrl+C...)
>
> Would that be cross-platform ?
>

No, that won't work at all.  'Ctrl-C' is a magic indicator to the
terminal driver to send SIGINT to the appropriate processes: it never
actually appears as an input and output character to a program unless
it's controlling the terminal in raw mode (where it loses its special
meaning).  If you're really insistent on using the sox(1) command-line
tools to play your sounds, then you'll have to send SIGINT or SIGTERM
in order to tell it to terminate (which can be done just by calling
the terminate() method).

Which is fine and will probably work OK subject to three restrictions:
1. Nothing in your application modifies the default handling of
SIGCHLD.  This means that the child process appears as a zombie (e.g.,
via 'ps ax') until the parent calls poll() or wait() methods to reap
it.
2. You only send signals while the process is alive or a zombie: once
the poll() or wait() methods  return something other than None, you
cannot safely send anymore signals.
3. You trap any errors returned by the send signal call.

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

python philosophical question - strong vs duck typing

[Sean Wolfe]

Hello everybody, I'm a happy pythonista newly subscribed to the group.
How is it going?
I have a theoretical / philosophical question regarding strong vs duck
typing in Python. Let's say we wanted to type strongly in Python and
were willing to compromise our code to the extent necessary, eg not
changing variable types or casting or whatever. Let's say there was a
methodology in Python to declare variable types.

The question is, given this possibility, would this get us closer to
being able to compile down to a language like C or C++?

What I am driving at is, if we are coding in python but looking for
more performance, what if we had an option to 1) restrict ourselves
somewhat by using strong typing to 2) make it easy to compile or
convert down to C++ and thereby gain more performance.

It seems to be that accepting the restrictions of strong typing might
be worth it in certain circumstances. Basically the option to use a
strongly-typed Python as desired. Does this get us closer to being
able to convert to Cpp? Does the Cython project have anything to do
with this?

Thanks!








-- 
A musician must make music, an artist must paint, a poet must write,
if he is to be ultimately at peace with himself.
- Abraham Maslow
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: .format vs. %

[Ian Kelly]

On Jan 3, 2012 6:55 AM, "Ethan Furman"  wrote:
>
> Ian Kelly wrote:
>>
>> I'm not sure it's true that "there are no plans to do so in the
>> foreseeable future."  According to the release notes from Python 3.0,
>> % formatting was supposed to be deprecated in Python 3.1.
>
>
> Eric Smith wrote (from a thread on pydev in 02-2011):
> > The last thread on this I have a reference to was in September 2009. I
> > think was basically the outcome:
> > http://mail.python.org/pipermail/python-dev/2009-September/092399.html
> >
> > So there will be no deprecation, just a gradual shift to PEP 3101
> > formatting.

Thanks, that link is very informative.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python philosophical question - strong vs duck typing

[Nathan Rice]

On Tue, Jan 3, 2012 at 1:13 PM, Sean Wolfe  wrote:
> Hello everybody, I'm a happy pythonista newly subscribed to the group.
> How is it going?
> I have a theoretical / philosophical question regarding strong vs duck
> typing in Python. Let's say we wanted to type strongly in Python and
> were willing to compromise our code to the extent necessary, eg not
> changing variable types or casting or whatever. Let's say there was a
> methodology in Python to declare variable types.

Do you think everyone who uses the code you write wants to deal with
your type decisions?

> The question is, given this possibility, would this get us closer to
> being able to compile down to a language like C or C++?

Declaring types would enable some additional optimizations, yes.  No,
it isn't worth it.

> What I am driving at is, if we are coding in python but looking for
> more performance, what if we had an option to 1) restrict ourselves
> somewhat by using strong typing to 2) make it easy to compile or
> convert down to C++ and thereby gain more performance.

Take a look at PyPy, with RPython.  That is the most future proof,
forward thinking way of doing what you want.

> It seems to be that accepting the restrictions of strong typing might
> be worth it in certain circumstances. Basically the option to use a
> strongly-typed Python as desired. Does this get us closer to being
> able to convert to Cpp? Does the Cython project have anything to do
> with this?

Declared typing is mostly annoying.  Implicit static typing is less
annoying, but still has issues.

Cython fills the same niche as PyPy's Rpython.  Use it if you have a
lot of C code you want to call, as you will get better performance
than a wrapper like SWIG.

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

Re: MOST COMMON QUESTIONS ASKED BY NON-MUSLIMS ?????????

[gene heskett]

On Tuesday, January 03, 2012 01:13:08 PM John Ladasky did opine:

> On Jan 3, 7:40 am, BV  wrote:
> > MOST COMMON QUESTIONS ASKED BY NON-MUSLIMS
> 
> Q0. Why do thousand-line religious posts appear in comp.lang.python?

Already discussed, at considerable length & I got told off.

The solution is to chop the link between google.groups and this list.  But 
that subject has been declared verboten. Too much inconvenience to ask the 
googlers to subscribe to the real list I guess.  Because my spamassassin 
has been trained on so much google (& yahoo too) originated spam, one 
poster here, Jerome, has his messages always caught.  He comes in thru the 
groups coupling and I have considered moving his messages to the ham 
folder, but realized all that would do is poison my bayes.

Since TPTB of this list don't care, neither do I, so his messages continue 
to be automatically fed to SA as spam, daily.  Shrug.
 
Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: 
I'm changing the CHANNEL ... But all I get is commercials for "RONCO
MIRACLE BAMBOO STEAMERS"!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Avoid race condition with Popen.send_signal

[Jérôme]

Tue, 3 Jan 2012 09:58:35 -0800 (PST)
Adam Skutt a écrit:

> If you're really insistent on using the sox(1) command-line tools to play
> your sounds, then you'll have to send SIGINT or SIGTERM in order to tell it
> to terminate (which can be done just by calling the terminate() method).
> 
> Which is fine and will probably work OK subject to three restrictions:
> 1. Nothing in your application modifies the default handling of
> SIGCHLD.  This means that the child process appears as a zombie (e.g.,
> via 'ps ax') until the parent calls poll() or wait() methods to reap
> it.
> 2. You only send signals while the process is alive or a zombie: once
> the poll() or wait() methods  return something other than None, you
> cannot safely send anymore signals.
> 3. You trap any errors returned by the send signal call.

Thank you very much for your patient explanations.

I sort of figured that out from your precedent messages and I was writing
the following :

---

I use poll() in idle task to follow the process's activity, then set a
variable if still in progress.

If I do the signalling in idle task as well, relying on that variable, there
should not be any race condition collateral damage. (If I did not, however, I
could send SIGINT between poll() and the variable being set.)

It just makes the code even heavier with each "stop sound" callback calling
GObject.idle_add() to ask for the work to be done in idle task, instead of
doing it right away.

---

I agree with the fact that ideally I would use another playback library.

The reason of my choice is "historical". This is my first python application.
I started simple and used beep for simplicity. 

Then, as I wanted to use the sound card, I searched for a library (I posted
here about that) and realized playing a sine wave was not that
straightforward. (I tried alsaaudio and had multithreading issues (posted
here as well).) 

As it was not that important to me (after all, it's just an exercise), I
decided to move on and use sox, as invoking it would be quite similar to
calling beep and I had already enough difficulties to face and other
priorities.

I guess I can always change my mind and use an audio library some day but I
was merely interested in the way signalling and processes work.

Thanks again.

-- 
Jérôme
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python philosophical question - strong vs duck typing

[D'Arcy Cain]

On 12-01-03 01:13 PM, Sean Wolfe wrote:

Hello everybody, I'm a happy pythonista newly subscribed to the group.


Welcome.


The question is, given this possibility, would this get us closer to
being able to compile down to a language like C or C++?


That's "a" question.  "The" question is "do you want to?"  Since we 
already run in machine language (doesn't everything) then how can you be 
sure that introducing another layer will improve performance?



What I am driving at is, if we are coding in python but looking for
more performance, what if we had an option to 1) restrict ourselves
somewhat by using strong typing to 2) make it easy to compile or
convert down to C++ and thereby gain more performance.


Where is your bottleneck?  I have seldom found Python to be it. 
Remember, almost everything you run was written in C.  Python is just 
the glue that binds it all together.


Consider ls(1) (dir in Windows/DOS) for example.  If you need a 
directory listing you type that and get it pretty quickly.  Is there a 
bottleneck?  Yes, it's you.  The command can probably do all of its work 
much faster than you can type the command.  Now put the command into a 
script.  Entering the command is no longer the bottleneck.  It's now the 
time it takes to access the drive.  Do we care?  Probably not and if we 
did there's probably not much we can do about it.  Python is simply a 
more powerful and efficient way to get to that machine language in a script.


If you do have a pure Python function that is a bottleneck and you 
believe that C can solve it, you can always write just that part in C. 
However, run some tests first to make sure.  99% of the time you can fix 
it algorithmically or else it wasn't the bottleneck that you thought it 
was.  And if it is and no one has already written a module for it, you 
just found a project to contribute back to the community.  :-)



It seems to be that accepting the restrictions of strong typing might
be worth it in certain circumstances. Basically the option to use a


So few as to not be worth changing the language for, especially when C 
is always available if you need it.


Cheers.

--
D'Arcy J.M. Cain  |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
IM: da...@vex.net
--
http://mail.python.org/mailman/listinfo/python-list

Re: MOST COMMON QUESTIONS ASKED BY NON-MUSLIMS ?????????

[D'Arcy Cain]

On 12-01-03 01:24 PM, gene heskett wrote:

The solution is to chop the link between google.groups and this list.  But
that subject has been declared verboten. Too much inconvenience to ask the
googlers to subscribe to the real list I guess.  Because my spamassassin


Perhaps they just need to be reminded from time to time that many of us 
have already "chopped the link" and for us there is no Google Groups on 
this list.  I never even saw the original message because everything 
from GG goes straight to /dev/null on my system.


Now if only I could automatically kill the replies to GG messages.  :-)

P.S. if you use Spamassassin:

:0 Hir
* ^List-Id:.*python-list.python.org
* ^From:.*@gmail.com
* ^Newsgroups:.*
/dev/null

--
D'Arcy J.M. Cain  |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
IM: da...@vex.net
--
http://mail.python.org/mailman/listinfo/python-list

Re: Repeating assertions in regular expression

[MRAB]

On 03/01/2012 09:45, Devin Jeanpierre wrote:

 \\b\\b and \\b{2} aren't equivalent ?


This sounds suspiciously like a bug!


 Why the wording is "should never" ? Repeating a zero-width assertion is not
 forbidden, for instance :


 import re
 re.compile("\\b\\b\w+\\b\\b")

 <_sre.SRE_Pattern object at 0xb7831140>




I believe this is meant to refer to arbitrary-length repetitions, such
as r'\b*', not simple concatenations like that. r'\b*' will abort the
whole match if is run on a boundary, because Python detects a
repetition of a zero-width match and decides this is an error.

r"\b+" can be optimised to r"\b", but r"\b*" can be optimised to r"". 
r"\b\b", r"\b\b\b", etc, can be optimised to r"\b".


So why doesn't it optimised?

Because every potential optimisation has a cost, which is the time it
would take to look for it.

That cost needs to be balanced against the potential benefit.

How often do you see repeated r"\b"?

Put simply, it doesn't occur often enough to be worth it. The cost
outweighs the potential benefit.
--
http://mail.python.org/mailman/listinfo/python-list

Re: python philosophical question - strong vs duck typing

[David Harks]

On 1/3/2012 12:13 PM, Sean Wolfe wrote:

if we are coding in python but looking for
more performance,


Are you in fact in this situation? Despite years of folks mentioning how 
Python is 'slower than C++', I've seen a project where a developer 
churned out a feature using Python's generators that performed much 
faster than the C++ implementation it replaced. It wasn't because the 
C++ was slower by nature; it's because it was harder to express the 
optimal algorithm in C++ so the C++ developer chose a sub-optimal 
approach in the interest of meeting a deadline.


There's always a tradeoff. Making a language less expressive 
(constraining ourselves) in favor of runtime performance is not always 
the right tradeoff.

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

Re: [Tutor] Parse multi line with re module.

[Joel Goldstick]

On Tue, Jan 3, 2012 at 12:51 PM, Robert Sjoblom
 wrote:
> On 3 January 2012 16:21, Joel Goldstick  wrote:
>> --
>
> Joel, when you start your emails with this (two dashes) some email
> readers (gmail among them) will think you're ending your email; I have
> to expand your post because it thinks that what is hidden is the
> signature. Just thought you should know.
>
>
> --
> best regards,
> Robert S.

Thank you.  I'm not sure how that happens.  I'll check my signature.


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

Re: MOST COMMON QUESTIONS ASKED BY NON-MUSLIMS ?????????

[Benjamin Kaplan]

On Tue, Jan 3, 2012 at 1:49 PM, D'Arcy Cain  wrote:
> On 12-01-03 01:24 PM, gene heskett wrote:
>>
>> The solution is to chop the link between google.groups and this list.  But
>> that subject has been declared verboten. Too much inconvenience to ask the
>> googlers to subscribe to the real list I guess.  Because my spamassassin
>
>
> Perhaps they just need to be reminded from time to time that many of us have
> already "chopped the link" and for us there is no Google Groups on this
> list.  I never even saw the original message because everything from GG goes
> straight to /dev/null on my system.
>
> Now if only I could automatically kill the replies to GG messages.  :-)
>
> P.S. if you use Spamassassin:
>
> :0 Hir
> * ^List-Id:.*python-list.python.org
> * ^From:.*@gmail.com
> * ^Newsgroups:.*
> /dev/null
>
> --

Wouldn't that just kill everything sent from a gmail account? That's
not the same thing as Google Groups. The mailing list posts, at least,
have an "Organization: http://groups.google.com"; header. You'd
probably be better off filtering on that.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Regular expression : non capturing groups are faster ?

[Devin Jeanpierre]

> You meant Perl Documentation, didn't you ?

I guess that works too. I did mean Python, though -- its intent is to
say "you shouldn't worry about this", but in the process it says "this
does not exist" (a lie).

"slightly better performance" would be accurate, as said by Goyvaerts/

-- Devin

On Tue, Jan 3, 2012 at 9:50 AM, candide  wrote:
> Le 03/01/2012 12:56, Devin Jeanpierre a écrit :
>>>
>>> The second assertion sounds more likely. It seems very odd that Python
>>> and
>>> Perl implementations are divergent on this point. Any opinion ?
>>
>>
>> The Python documentation oversimplifies.
>
>
> You meant Perl Documentation, didn't you ?
>
>
> It's a commun opinion that non-capturing groups have a price (minor), for
> instance Jan Goyvaerts, a well known regular expression guru, refering to
> Python code, tells :
>
>
> non-capturing groups (...)  offer (slightly) better performance as the regex
> engine doesn't have to keep track of the text matched by non-capturing
> groups.
>
>
> [link is there :
> http://stackoverflow.com/questions/2703029/why-regular-expressions-non-capturing-group-is-not-working]
>
>
>
> It seems Javascript performs better respect to non-capturing groups :
> http://jsperf.com/regex-capture-vs-non-capture
>
> The same for java : http://eyalsch.wordpress.com/2009/05/21/regex/
> (no benchmarks).
>
> For my part, Python tests didn't show any kind of significative penality.
> --
> http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Repeating assertions in regular expression

[Devin Jeanpierre]

> Put simply, it doesn't occur often enough to be worth it. The cost
> outweighs the potential benefit.

I don't buy it. You could backtrack instead of failing for \b+ and
\b*, and it would be almost as fast as this optimization.

-- Devin

On Tue, Jan 3, 2012 at 1:57 PM, MRAB  wrote:
> On 03/01/2012 09:45, Devin Jeanpierre wrote:
>>>
>>>  \\b\\b and \\b{2} aren't equivalent ?
>>
>>
>> This sounds suspiciously like a bug!
>>
>>>  Why the wording is "should never" ? Repeating a zero-width assertion is
>>> not
>>>  forbidden, for instance :
>>>
>>  import re
>>  re.compile("\\b\\b\w+\\b\\b")
>>>
>>>  <_sre.SRE_Pattern object at 0xb7831140>
>>
>>
>>
>> I believe this is meant to refer to arbitrary-length repetitions, such
>> as r'\b*', not simple concatenations like that. r'\b*' will abort the
>> whole match if is run on a boundary, because Python detects a
>> repetition of a zero-width match and decides this is an error.
>>
> r"\b+" can be optimised to r"\b", but r"\b*" can be optimised to r"".
> r"\b\b", r"\b\b\b", etc, can be optimised to r"\b".
>
> So why doesn't it optimised?
>
> Because every potential optimisation has a cost, which is the time it
> would take to look for it.
>
> That cost needs to be balanced against the potential benefit.
>
> How often do you see repeated r"\b"?
>
> Put simply, it doesn't occur often enough to be worth it. The cost
> outweighs the potential benefit.
> --
> http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: MOST COMMON QUESTIONS ASKED BY NON-MUSLIMS ?????????

[D'Arcy Cain]

On 12-01-03 02:24 PM, Benjamin Kaplan wrote:

:0 Hir
* ^List-Id:.*python-list.python.org
* ^From:.*@gmail.com
* ^Newsgroups:.*
/dev/null

--


Wouldn't that just kill everything sent from a gmail account? That's
not the same thing as Google Groups. The mailing list posts, at least,
have an "Organization: http://groups.google.com"; header. You'd
probably be better off filtering on that.


Possibly.  I don't remember seeing that header at the time that I 
created the recipe.  I'll have to try that.


In any case, the above doesn't kill everything from gmail, only messages 
from gmail that come through the news/mlist gateway.


--
D'Arcy J.M. Cain  |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
IM: da...@vex.net
--
http://mail.python.org/mailman/listinfo/python-list

Re: MOST COMMON QUESTIONS ASKED BY NON-MUSLIMS ?????????

[David Robinow]

On Tue, Jan 3, 2012 at 2:24 PM, Benjamin Kaplan
 wrote:
> On Tue, Jan 3, 2012 at 1:49 PM, D'Arcy Cain  wrote:
>> On 12-01-03 01:24 PM, gene heskett wrote:
>>>
>>> The solution is to chop the link between google.groups and this list.  But
>>> that subject has been declared verboten. Too much inconvenience to ask the
>>> googlers to subscribe to the real list I guess.  Because my spamassassin
>>
>> Perhaps they just need to be reminded from time to time that many of us have
>> already "chopped the link" and for us there is no Google Groups on this
>> list.  I never even saw the original message because everything from GG goes
>> straight to /dev/null on my system.
>>
>> Now if only I could automatically kill the replies to GG messages.  :-)
>>
>> P.S. if you use Spamassassin:
>>
>> :0 Hir
>> * ^List-Id:.*python-list.python.org
>> * ^From:.*@gmail.com
>> * ^Newsgroups:.*
>> /dev/null
>>
> Wouldn't that just kill everything sent from a gmail account? That's
> not the same thing as Google Groups. The mailing list posts, at least,
> have an "Organization: http://groups.google.com"; header. You'd
> probably be better off filtering on that.
 Interesting. I read the list using gmail, and I never saw the
original post. IIn fact I rarely see any spam at all. Apparently,
somebody at google knows how to identify spam. I wonder why they can't
do it for google groups.
 [I also wonder if anybody will see this post, coming from an evil source.]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python philosophical question - strong vs duck typing

[Neil Cerutti]

On 2012-01-03, David Harks  wrote:
> On 1/3/2012 12:13 PM, Sean Wolfe wrote:
>> if we are coding in python but looking for
>> more performance,
>
> Are you in fact in this situation? Despite years of folks
> mentioning how Python is 'slower than C++', I've seen a project
> where a developer churned out a feature using Python's
> generators that performed much faster than the C++
> implementation it replaced. It wasn't because the C++ was
> slower by nature; it's because it was harder to express the
> optimal algorithm in C++ so the C++ developer chose a
> sub-optimal approach in the interest of meeting a deadline.

I was again looking through The Practice of Programming
(Kernighan & Pike) today, and the chapter on the Markov chain
program makes similar tradeoffs. For educational purposes they
implement the program in several languages, and the C
implemenation is fastest by far. The C++ implementation is
surprisingly not close in performance to the C version, for two
main reasons.

1. They used a std::deque to store the prefixes, when a std::list
   is the correct container. They point this out in a note on the
   poor performance of the C++ program, but do not note the irony
   that they had automatically used a singly-linked list in C.

2. When building the data structure in C they store only
   pointers to the original text, which they munge in memory to
   create zero-terminated strings. This is idiomatic C.
   But there's no reason C++ can't do a similar optimization.
   A std::list is certainly possible, but loses you most
   of the benefits of the standard containers. Best is probably
   to create a registry of words using a std::map, with your lists storing references to words in
   the registry. You still have to copy of the text, but only
   once. The C++ implementation starts to smell sort of like
   Python. ;)

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

Re: .format vs. %

[Neil Cerutti]

On 2012-01-03, Stefan Krah  wrote:
> Andrew Berg  wrote:
>> To add my opinion on it, I find format() much more readable and easier
>> to understand (with the exception of the {} {} {} {} syntax), and would
>> love to see %-style formatting phased out.
>
> For me the %-style is much more readable. Also, it is significantly
> faster:
>
> $ ./python -m timeit -n 100 '"%s" % 7.928137192'
> 100 loops, best of 3: 0.0164 usec per loop

I have done a little more investigating, and the above is
arguably not fair. Python is interpolating that string at compile
time, as far as I can tell. Pretty cool, and not possible with
.format, but it's just regurgitating a string literal over and
over, which isn't of much interest.

% is faster, but not by an order of magnitude.

On my machine:

C:\WINDOWS>python -m timeit -n 100 -s "n=7.92" "'%s' % n"
100 loops, best of 3: 0.965 usec per loop

C:\WINDOWS>python -m timeit -n 100 -s "n=7.92" "'{}'.format(n)"
100 loops, best of 3: 1.17 usec per loop

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

Re: .format vs. %

[Ethan Furman]

Ian Kelly wrote:

http://mail.python.org/pipermail/python-dev/2009-September/092399.html


Thanks, that link is very informative.



Here's the link to the last discussion last February:

http://mail.python.org/pipermail/python-dev/2011-February/108155.html

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

Unable to install xmldiff package on WIndows7

[hisan]

Hi All

i have downloaded "xmldiff-0.6.10" from their official site (http://
www.logilab.org/859).
I have tried installing the same on my 32 bit Windows 7 OS using the
command "setup.py install" but below exceptions are thrown in the
console.
please help me out in installing this package on Windows

Exceptions thrown while installing


C:\Users\santosh\Downloads\xmldiff-0.6.10>setup.py build
running build
running build_py
package init file '.\test\__init__.py' not found (or not a regular
file)
package init file '.\test\__init__.py' not found (or not a regular
file)
running build_ext
building 'xmldiff.maplookup' extension
gcc -mno-cygwin -mdll -O -Wall -ID:\Python26\include -ID:\Python26\PC -
c extensions/maplookup.c -o b
uild\temp.win32-2.6\Release\extensions\maplookup.o
error: command 'gcc' failed: No such file or directory


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

Re: python philosophical question - strong vs duck typing

[Evan Driscoll]

On 1/3/2012 13:13, Sean Wolfe wrote:
> What I am driving at is, if we are coding in python but looking for
> more performance, what if we had an option to 1) restrict ourselves
> somewhat by using strong typing to 2) make it easy to compile or
> convert down to C++ and thereby gain more performance.
I'm not sure it helps with compiling to C or C++ (that is neither
necessary nor sufficient for being a high performance language), but it
has the potential for helping quite a lot with performance. If you read
stuff written by evangelical Common Lisp folks, they tout CL's optional
type annotations as providing a mechanism for getting near-C-like
performance. I haven't tested that myself though.

Evan




signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: .format vs. %

[Devin Jeanpierre]

> "one obvious way" != "only one way"

Which way is the obvious way? Why is it obvious?

For me, sprintf-formatting is "obviously" easier to use (less typing)
unless you're pulling values from a dictionary or object, or already
have all the variables stored in a dict you can pass in with **d.

-- Devin

On Tue, Jan 3, 2012 at 8:26 AM, Ethan Furman  wrote:
> Ian Kelly wrote:
>>
>> I'm not sure it's true that "there are no plans to do so in the
>> foreseeable future."  According to the release notes from Python 3.0,
>> % formatting was supposed to be deprecated in Python 3.1.
>
>
> Eric Smith wrote (from a thread on pydev in 02-2011):
>> The last thread on this I have a reference to was in September 2009. I
>> think was basically the outcome:
>> http://mail.python.org/pipermail/python-dev/2009-September/092399.html
>>
>> So there will be no deprecation, just a gradual shift to PEP 3101
>> formatting.
>
>
> Ian Kelly wrote:
>>
>> Maybe there was a discussion on py-dev
>> where it was decided that % formatting would not be deprecated after
>> all (in which case the misleading "obsolete" note really ought to be
>> removed from the documentation).
>
>
> Agreed that this is a documentation bug.
>
>
> Ian Kelly wrote:
>>
>> The reason for deprecating it is because Python currently has no fewer
>> than three mechanisms for string formatting (not even including
>> ordinary string concatenation), which according to the Zen of Python
>> is two too many.
>
>
> "one obvious way" != "only one way"
>
> ~Ethan~
> --
> http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: .format vs. %

[Joshua Landau]

On 3 January 2012 19:46, Neil Cerutti  wrote:

> On 2012-01-03, Stefan Krah  wrote:
> > Andrew Berg  wrote:
> >> To add my opinion on it, I find format() much more readable and easier
> >> to understand (with the exception of the {} {} {} {} syntax), and would
> >> love to see %-style formatting phased out.
> >
> > For me the %-style is much more readable. Also, it is significantly
> > faster:
> >
> > $ ./python -m timeit -n 100 '"%s" % 7.928137192'
> > 100 loops, best of 3: 0.0164 usec per loop
>
> I have done a little more investigating, and the above is
> arguably not fair. Python is interpolating that string at compile
> time, as far as I can tell. Pretty cool, and not possible with
> .format, but it's just regurgitating a string literal over and
> over, which isn't of much interest.
>
> % is faster, but not by an order of magnitude.
>
> On my machine:
>
> C:\WINDOWS>python -m timeit -n 100 -s "n=7.92" "'%s' % n"
> 100 loops, best of 3: 0.965 usec per loop
>
> C:\WINDOWS>python -m timeit -n 100 -s "n=7.92" "'{}'.format(n)"
> 100 loops, best of 3: 1.17 usec per loop


Cool! And you can make up half the difference, too:

%~> python -m timeit -n 100 -s "n=7.92" "'%s' % n"
100 loops, best of 3: 1.27 usec per loop
%~> python -m timeit -n 100 -s "n=7.92" "'{}'.format(n)"
100 loops, best of 3: 1.81 usec per loop
%~> python -m timeit -n 100 -s "n=7.92; x='{}'.format" "x(n)"
100 loops, best of 3: 1.51 usec per loop
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Regular expression : non capturing groups are faster ?

[Octavian Rasnita]

From: "Devin Jeanpierre" 
Subject: Re: Regular expression : non capturing groups are faster ?


>> You meant Perl Documentation, didn't you ?
> 
> I guess that works too. I did mean Python, though -- its intent is to
> say "you shouldn't worry about this", but in the process it says "this
> does not exist" (a lie).


**
However, the Perl documentation doesn't lie.

I tested 10 million matches on my computer using capturing groups and it took ~ 
6 seconds, but only ~ 2 seconds with non-capturing params.

So yes, it is very fast anyway, but ~ 3 times faster with non-capturing params, 
so there is a difference.

Octavian

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

Re: MOST COMMON QUESTIONS ASKED BY NON-MUSLIMS ?????????

[Devin Jeanpierre]

>  Interesting. I read the list using gmail, and I never saw the
> original post. IIn fact I rarely see any spam at all. Apparently,
> somebody at google knows how to identify spam. I wonder why they can't
> do it for google groups.
>  [I also wonder if anybody will see this post, coming from an evil source.]

Same here. I thought I might have accidentally misconfigured my
mailbox filter to not accept google group posts, but that doesn't seem
to be the case -- it isn't anywhere in gmail.

-- Devin

On Tue, Jan 3, 2012 at 2:42 PM, David Robinow  wrote:
> On Tue, Jan 3, 2012 at 2:24 PM, Benjamin Kaplan
>  wrote:
>> On Tue, Jan 3, 2012 at 1:49 PM, D'Arcy Cain  wrote:
>>> On 12-01-03 01:24 PM, gene heskett wrote:

 The solution is to chop the link between google.groups and this list.  But
 that subject has been declared verboten. Too much inconvenience to ask the
 googlers to subscribe to the real list I guess.  Because my spamassassin
>>>
>>> Perhaps they just need to be reminded from time to time that many of us have
>>> already "chopped the link" and for us there is no Google Groups on this
>>> list.  I never even saw the original message because everything from GG goes
>>> straight to /dev/null on my system.
>>>
>>> Now if only I could automatically kill the replies to GG messages.  :-)
>>>
>>> P.S. if you use Spamassassin:
>>>
>>> :0 Hir
>>> * ^List-Id:.*python-list.python.org
>>> * ^From:.*@gmail.com
>>> * ^Newsgroups:.*
>>> /dev/null
>>>
>> Wouldn't that just kill everything sent from a gmail account? That's
>> not the same thing as Google Groups. The mailing list posts, at least,
>> have an "Organization: http://groups.google.com"; header. You'd
>> probably be better off filtering on that.
>  Interesting. I read the list using gmail, and I never saw the
> original post. IIn fact I rarely see any spam at all. Apparently,
> somebody at google knows how to identify spam. I wonder why they can't
> do it for google groups.
>  [I also wonder if anybody will see this post, coming from an evil source.]
> --
> http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Setting an environment variable.

[Nobody]

On Tue, 03 Jan 2012 15:45:20 +1000, Ashton Fagg wrote:

> I'm working with an embedded machine, which is using a Python script to 
> oversee the acquisition of some data. The supervisor script, which is 
> run by crontab every 5 minutes, relies on an environment variable to be 
> set. I've tried to set the environment variable inside crontab, however 
> this doesn't work when the script runs.

Odd.

> Is there a nice way to do this inside the supervisor script itself? 
> Would an os.system("export foo=/bar/foo/bar") at the very beginning of 
> the script do what I want?

No. It would set the variable only for the child process created by
os.system(), which would be pointless.

To set an environment variable for the current process (and, by default,
any child processes), modify os.environ, e.g.:

os.environ['foo'] = '/bar/foo/bar'

You can set environment variables for specific child processes created via
subprocess.Popen() using the env= parameter, e.g.:

env = os.environ.copy()
env['foo'] = '/bar/foo/bar'
p = subprocess.Popen(..., env=env)

If env= isn't used, the child will inherit the parent's environment.

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

Re: .format vs. %

[Ethan Furman]

Devin Jeanpierre wrote:

"one obvious way" != "only one way"


Which way is the obvious way? Why is it obvious?


Apparently, %-style is obvious to C and similar coders, while {}-style 
is obvious to Java and similar coders.


:)

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

Re: python philosophical question - strong vs duck typing

[Terry Reedy]

On 1/3/2012 1:13 PM, Sean Wolfe wrote:


I have a theoretical / philosophical question regarding strong vs duck
typing in Python. Let's say we wanted to type strongly in Python and


Python objects are strongly typed, in any sensible meaning of the term.
What you mean is statically or explicitly typing names.


were willing to compromise our code to the extent necessary, eg not
changing variable types or casting or whatever. Let's say there was a
methodology in Python to declare variable types.

The question is, given this possibility, would this get us closer to
being able to compile down to a language like C or C++?


Cython compiles Python as is to C. It also gives the option to add type 
annotations to names to get faster code. Shredskin compiles a subset of 
Python, or a subset of usages, to C, with similar benefits.


--
Terry Jan Reedy

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

Re: Regular expression : non capturing groups are faster ?

[Devin Jeanpierre]

> I tested 10 million matches on my computer using capturing groups and it took 
> ~ 6 seconds, but only ~ 2 seconds with non-capturing params.

Are you talking about Python or Perl? I can't reproduce this in
Python. Best I can do is a 3:4 ratio between running times. ('(a)*
versus '(?:a)*)

Also, wouldn't say "very fast". Compare those two groups with 'a*'.
I'm not sure what's going on there.

-- Devin

On Tue, Jan 3, 2012 at 3:07 PM, Octavian Rasnita  wrote:
> From: "Devin Jeanpierre" 
> Subject: Re: Regular expression : non capturing groups are faster ?
>
>
>>> You meant Perl Documentation, didn't you ?
>>
>> I guess that works too. I did mean Python, though -- its intent is to
>> say "you shouldn't worry about this", but in the process it says "this
>> does not exist" (a lie).
>
>
> **
> However, the Perl documentation doesn't lie.
>
> I tested 10 million matches on my computer using capturing groups and it took 
> ~ 6 seconds, but only ~ 2 seconds with non-capturing params.
>
> So yes, it is very fast anyway, but ~ 3 times faster with non-capturing 
> params, so there is a difference.
>
> Octavian
>
> --
> http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: .format vs. %

[Ethan Furman]

Neil Cerutti wrote:

On 2012-01-03, Stefan Krah  wrote:

Andrew Berg  wrote:

To add my opinion on it, I find format() much more readable and easier
to understand (with the exception of the {} {} {} {} syntax), and would
love to see %-style formatting phased out.

For me the %-style is much more readable. Also, it is significantly
faster:

$ ./python -m timeit -n 100 '"%s" % 7.928137192'
100 loops, best of 3: 0.0164 usec per loop


I have done a little more investigating, and the above is
arguably not fair. Python is interpolating that string at compile
time, as far as I can tell. Pretty cool, and not possible with
.format, but it's just regurgitating a string literal over and
over, which isn't of much interest.

% is faster, but not by an order of magnitude.

On my machine:

C:\WINDOWS>python -m timeit -n 100 -s "n=7.92" "'%s' % n"
100 loops, best of 3: 0.965 usec per loop

C:\WINDOWS>python -m timeit -n 100 -s "n=7.92" "'{}'.format(n)"
100 loops, best of 3: 1.17 usec per loop



Good information.  Thanks.

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

Re: .format vs. %

[Stefan Krah]

Neil Cerutti  wrote:
> On 2012-01-03, Stefan Krah  wrote:
> > $ ./python -m timeit -n 100 '"%s" % 7.928137192'
> > 100 loops, best of 3: 0.0164 usec per loop
> 
> % is faster, but not by an order of magnitude.
> 
> On my machine:
> 
> C:\WINDOWS>python -m timeit -n 100 -s "n=7.92" "'%s' % n"
> 100 loops, best of 3: 0.965 usec per loop
> 
> C:\WINDOWS>python -m timeit -n 100 -s "n=7.92" "'{}'.format(n)"
> 100 loops, best of 3: 1.17 usec per loop

Indeed, I was a bit surprised by the magnitude of the difference.

Your timings seem to be in line with the difference seen in the
real-world benchmark. It isn't a big deal, considering that the
numeric formatting functions have to so many options, e.g:

>>> "{:020,}".format(712312312.2)
'00,000,712,312,312.2'


Still, it's nice to have a faster choice.


Stefan Krah


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

Re: python philosophical question - strong vs duck typing

[Devin Jeanpierre]

> Python objects are strongly typed, in any sensible meaning of the term.

There are people that hold definitions of strong typing that preclude
Python. Those people think their definition is reasonable, but at the
same time haven't confused static typing with strong typing. I guess
the problem is that this boils down to opinion, but you're stating it
as incontrovertible fact.

> What you mean is statically or explicitly typing names.

Right, yes.

> Cython compiles Python as is to C. It also gives the option to add type
> annotations to names to get faster code. Shredskin compiles a subset of
> Python, or a subset of usages, to C, with similar benefits.

I seem to remember there being a project which compiled the Python
bytecode down to C in a very dumb way (basically just making C code
that creates the bytecode and executes it in the CPython VM). I can't
find it, though.

Anyway, compiling Python to C is actually fairly trivial. People
usually mean something else by it, though.

-- Devin

On Tue, Jan 3, 2012 at 3:38 PM, Terry Reedy  wrote:
> On 1/3/2012 1:13 PM, Sean Wolfe wrote:
>
>> I have a theoretical / philosophical question regarding strong vs duck
>> typing in Python. Let's say we wanted to type strongly in Python and
>
>
> Python objects are strongly typed, in any sensible meaning of the term.
> What you mean is statically or explicitly typing names.
>
>
>> were willing to compromise our code to the extent necessary, eg not
>> changing variable types or casting or whatever. Let's say there was a
>> methodology in Python to declare variable types.
>>
>> The question is, given this possibility, would this get us closer to
>> being able to compile down to a language like C or C++?
>
>
> Cython compiles Python as is to C. It also gives the option to add type
> annotations to names to get faster code. Shredskin compiles a subset of
> Python, or a subset of usages, to C, with similar benefits.
>
> --
> Terry Jan Reedy
>
> --
> http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python philosophical question - strong vs duck typing

[Joshua Landau]

On 3 January 2012 20:38, Terry Reedy  wrote:

> On 1/3/2012 1:13 PM, Sean Wolfe wrote:
>
>  I have a theoretical / philosophical question regarding strong vs duck
>> typing in Python. Let's say we wanted to type strongly in Python and
>>
>
> Python objects are strongly typed, in any sensible meaning of the term.
> What you mean is statically or explicitly typing names.
>
>
>  were willing to compromise our code to the extent necessary, eg not
>> changing variable types or casting or whatever. Let's say there was a
>> methodology in Python to declare variable types.
>>
>> The question is, given this possibility, would this get us closer to
>> being able to compile down to a language like C or C++?
>>
>
> Cython compiles Python as is to C. It also gives the option to add type
> annotations to names to get faster code. Shredskin compiles a subset of
> Python, or a subset of usages, to C, with similar benefits.


A minor point of clarification here: although what you wrote is technically
true, it's also misleading.

AFAIK both Cython and Shedskin compile only a subset of Python, but the
magnitude difference they drop off is large. Almost everything is Cython
compliant, and that should just grow, but there are a few flakes here and
there. However, Shedskin is a well defined subset, and does not encompass
the whole of Python and will never do so.

Shedskin *truly* compiles to C and thus is afflicted with several
restrictions such as static typing.

Cython is a lot less clear. What it compiles to is basically bytecode
written in C. Instead of CPython reading the bytecode and the bytecode
being parsed and then executed, *the computer natively parses the bytecode
which tells CPython what to do*. This reduces a lot of overhead in tight
loops, but doesn't help much in the general case.

So why sacrifice so much for so little gain? Well - when your bytecode is
C, you can interoperate other C code right inside. If you make some C
variables you can do C-math inside your Python with no real overhead.
Additionally, you can call C libraries really easily inside this code. What
it results in is a really easy way to optimise the 5% that's slowing your
code, and instead of rewriting it in C you use C-with-python-syntax. The
types are sill horrible, though ;)

--

To  answer Devin:
You're probably thinking of Cython ^^.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python philosophical question - strong vs duck typing

[Terry Reedy]

On 1/3/2012 4:06 PM, Devin Jeanpierre wrote:

Python objects are strongly typed, in any sensible meaning of the term.


There are people that hold definitions of strong typing that preclude
Python. Those people think their definition is reasonable, but at the


Can you give an actual example of such a definition of 'strongly typed 
object' that excludes Python objects?



same time haven't confused static typing with strong typing. I guess
the problem is that this boils down to opinion, but you're stating it
as incontrovertible fact.


This strikes me as petty hair-splitting.

1. By tacking on the qualification, I was acknowledging that someone, 
somewhere, might controvert it. If you allow for arbitrary redefinitions 
of words, you could claim that any statement is an opinion. So what?


2. It ignores the context established by the OP who began with 'Let's 
say we wanted to type strongly in Python' and continued with a question 
about declarations and compilation specifically to C or C++.


In that context, I think my statement qualifies as a fact.

--
Terry Jan Reedy

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

Re: Spamming PyPI with stupid packages

[Ben Finney]

Steven D'Aprano  writes:

> The joke cuts both ways.

This is the Just World fallacy: you're implying that, because the same
joke can be applied equally well to women or men, that therefore it is
equally harmful. The fallacy is to ignore the fact that the playing
field is not level.

Yes, that same joke can semantically be applied equally to men. But it
is disproportionately harmful to women, because there is a significantly
greater level of sexism against women already. Apologetics defending
sexist jokes against women delay the time when women can feel that they
are as free to participate in this community as men.

Actions appropriate for a level playing field are not appropriate in our
case.

-- 
 \   “We must respect the other fellow's religion, but only in the |
  `\   sense and to the extent that we respect his theory that his |
_o__) wife is beautiful and his children smart.” —Henry L. Mencken |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Spamming PyPI with stupid packages

[Ben Finney]

Peter Otten <__pete...@web.de> writes:

> If you want more women in IT go to a local school and show the girls
> things they can do with a computer that they find fun and interesting.
> If you have a daughter try more Lego and less Barbies.

I have no objection to doing those things *as well as* rejecting sexist
jokes in our community.

-- 
 \ “Science is a way of trying not to fool yourself. The first |
  `\ principle is that you must not fool yourself, and you are the |
_o__)   easiest person to fool.” —Richard P. Feynman, 1964 |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Is there anyway to selectively inherit/import a class/module?

[Peter]

I have a program that talks to a device via a serial interface.
Structurally it looks like this:

Program A -> module B -> Serial

I want to add a protocol layer around the serial port without
modifying any of the modules above and I want to be able to use BOTH
cases of the program whenever convenient, so at first it seemed like a
simple case of sub-classing the Serial class and then (this is the
problem) somehow use either the original serial class definition when
I wanted the original program functionality or the new class when I
wanted the extra layer present.

Module B has

import serial

so my first thought was to put the new module in the current directory
and call it "serial.py". This would allow me to run the program with
the new Serial class and when I didn't want that extra layer, all I
had to do was rename the module to something else and let Module B
pick up serial from the site-package area. But (obviously) this
doesn't work because the new class's first few statements are:

import serial

Class Serial(serial.Serial):

So when Module B does the import (and gets the new class definition),
I get an error message (as the new definition is loaded):

AttributeError: 'module' object has no attribute 'Serial' on the Class
declaration statement.

Is there anyway to have Module B use the new class without modifying
the content of Module B?

The only other alternative I can think of is to create a copy of the
original program, rename the new class file and have two complete
copies of the program but that is not ideal :-)

Thanks
Peter

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

Re: python philosophical question - strong vs duck typing

[Ben Finney]

Sean Wolfe  writes:

> Hello everybody, I'm a happy pythonista newly subscribed to the group.

Welcome!

> I have a theoretical / philosophical question regarding strong vs duck
> typing in Python. Let's say we wanted to type strongly in Python

There may be an unstated assumption there, and your wording confuses me.

Are you aware that Python has strong typing *and* duck typing,
simultaneously?

Every Python object is strongly-typed: they know exactly what type they
are, what operations are permitted with objects of other types, and
won't pretend to be a different type. (So an object of, e.g., type
‘int’, won't allow addition of itself with an object of type ‘str’.)

“Strongly-typed” is one end of a spectrum whose opposite end is
“weakly-typed”. Weakly-typed objects are in languages like e.g. PHP,
where an integer object can be added to a string object.

Every Python object allows duck typing: its operations are available to
any code that wants to use that functionality, regardless of what type
the client may assume it's working with. (This allows an object of,
e.g., type ‘StringIO’, which has no relationship to the ‘file’ type, to
be used by functions expecting a file object.)

What do you mean to convey by “strong vs. duck typing”?

> and were willing to compromise our code to the extent necessary, eg
> not changing variable types or casting or whatever. Let's say there
> was a methodology in Python to declare variable types.

Python does not have variables in the sense of languages like C; rather,
Python has references bound to objects. A reference (e.g. a name, or a
list index, etc.) never has a type. An object always has a type.

You may be thinking of “static typing” (identifiers have types, and
won't allow themselves to refer to an object of a different type),
versus “dynamic typing” (identifiers are ignorant of types – this is
what you have in Python).

> What I am driving at is, if we are coding in python but looking for
> more performance, what if we had an option to 1) restrict ourselves
> somewhat by using strong typing to 2) make it easy to compile or
> convert down to C++ and thereby gain more performance.

I would need to know what you mean instead of “strong typing”, because
Python already has that.

-- 
 \“If we ruin the Earth, there is no place else to go. This is |
  `\not a disposable world, and we are not yet able to re-engineer |
_o__)  other planets.” —Carl Sagan, _Cosmos_, 1980 |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [OT] Book authoring

[wesley chun]

fwiw, i've given a related talk a couple of times on this subject, the
most recent of which was at EuroPython this summer:
http://ep2011.europython.eu/conference/talks/writing-books-using-python-open-source-software

the content includes a couple of the tools mentioned in this thread as
well as some author case studies. slide deck's available there too.

cheers,
--wesley


On Dec 9 2011, 7:43 am, Nick Dokos  wrote:
> Grant Edwards  wrote:
> > On 2011-12-09, Miki Tebeka  wrote:
> > > Greetings,
>
> > > Any recommendations for abook authoringsystem that supports the following:
> > > 1. Code examples (with syntax highlighting and line numbers)
> > > 2. Output HTML, PDF, ePub ...
> > > 3. Automatic TOC and index
> > > 4. Search (in HTML) - this is a "nice to have"
>
> >http://en.wikipedia.org/wiki/Lightweight_markup_language
>
> > I've used asciidoc extensively and reStructuredText a little. Asciidoc
> > will produce all the formats you mentioned (though I've only refularly
> > used HTML and PDF). reStructuredText is what's used for Python docs
> > isn't it?
>
> > > Can I somehow use Sphinx?
>
> > Don't know what Sphinx is.
>
> I think Sphinx is used for the python docs: it sits atop rST and does
> all the transformations/processing to produce the desired output
> (http://sphinx.pocoo.org)
>
> > And there's always the old stand-by LaTeX, but it's a bit more
> > heavyweight with more of a learning curve.  OTOH, it does produce
> > text-book quality output.
>
> There is also orgmode, which has been used for a few books
> (http://orgmode.org). I know it does HTML and PDF (the latter through
> latex), but I'm not sure about ePub: ISTR somebody actually did ePub for
> his book but I don't remember details. The indexing is manual:
> add #+index: foo entries as required.  But in general, imo, automatic
> indexing for books sucks raw eggs (it works much better for highly
> regular source code like the python source base).
>
> Nick


-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"Core Python", Prentice Hall, (c)2007,2001
"Python Fundamentals", Prentice Hall, (c)2009
    http://corepython.com

wesley.chun : wescpy-gmail.com : @wescpy/+wescpy
python training and technical consulting
cyberweb.consulting : silicon valley, ca
http://cyberwebconsulting.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Large list in memory slows Python

[Benoit Thiell]

Hi.

I am experiencing a puzzling problem with both Python 2.4 and Python
2.6 on CentOS 5. I'm looking for an explanation of the problem and
possible solutions. Here is what I did:

Python 2.4.3 (#1, Sep 21 2011, 19:55:41)
IPython 0.8.4 -- An enhanced Interactive Python.

In [1]: def test():
   ...: return [(i,) for i in range(10**6)]

In [2]: %time x = test()
CPU times: user 0.82 s, sys: 0.04 s, total: 0.86 s
Wall time: 0.86 s

In [4]: big_list = range(50 * 10**6)

In [5]: %time y = test()
CPU times: user 9.11 s, sys: 0.03 s, total: 9.14 s
Wall time: 9.15 s

As you can see, after creating a list of 50 million integers, creating
the same list of 1 million tuples takes about 10 times longer than the
first time.

I ran these tests on a machine with 144GB of memory and it is not
swapping. Before creating the big list of integers, IPython used 111MB
of memory; After the creation, it used 1664MB of memory.

Thanks for your time.
Cheers.

-- 
Benoit Thiell
The SAO/NASA Astrophysics Data System
http://adswww.harvard.edu/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Large list in memory slows Python

[Peter Otten]

Benoit Thiell wrote:

> I am experiencing a puzzling problem with both Python 2.4 and Python
> 2.6 on CentOS 5. I'm looking for an explanation of the problem and
> possible solutions. Here is what I did:
> 
> Python 2.4.3 (#1, Sep 21 2011, 19:55:41)
> IPython 0.8.4 -- An enhanced Interactive Python.
> 
> In [1]: def test():
>...: return [(i,) for i in range(10**6)]
> 
> In [2]: %time x = test()
> CPU times: user 0.82 s, sys: 0.04 s, total: 0.86 s
> Wall time: 0.86 s
> 
> In [4]: big_list = range(50 * 10**6)
> 
> In [5]: %time y = test()
> CPU times: user 9.11 s, sys: 0.03 s, total: 9.14 s
> Wall time: 9.15 s
> 
> As you can see, after creating a list of 50 million integers, creating
> the same list of 1 million tuples takes about 10 times longer than the
> first time.
> 
> I ran these tests on a machine with 144GB of memory and it is not
> swapping. Before creating the big list of integers, IPython used 111MB
> of memory; After the creation, it used 1664MB of memory.

In older Pythons the heuristic used to decide when to run the cyclic garbage 
collection is not well suited for the creation of many objects in a row.
Try switching it off temporarily with

import gc
gc.disable()
# create many objects that are here to stay
gc.enable()

You may also encorporate that into your test function:

def test():
gc.disable()
try:
return [...]
finally:
gc.enable()


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

Re: python philosophical question - strong vs duck typing

[Ben Finney]

Terry Reedy  writes:

> On 1/3/2012 1:13 PM, Sean Wolfe wrote:
>
> > I have a theoretical / philosophical question regarding strong vs
> > duck typing in Python. Let's say we wanted to type strongly in
> > Python
>
> Python objects are strongly typed, in any sensible meaning of the
> term. What you mean is statically or explicitly typing names.

For more on the various spectrums of type systems, and the terms to use,
see https://en.wikipedia.org/wiki/Type_system>.

-- 
 \  “If I haven't seen as far as others, it is because giants were |
  `\   standing on my shoulders.” —Hal Abelson |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Newbie Help

[mixolydian]

I want to get into Python progamming for both local database applications and 
dynamic web pages. Maybe some Q&D scripts.
There is a ton of excellent language books.

I have downloaded and installed 2.7.2 and got it working by pasting samples 
into IDLE, and uploading to my web server and doing trial CGI samples. 
So far, so good.

I would like some advice on:
  1. IDEs
  2. GUI tools, tkinter and others
  3. An integrated web server package for Win Vista for testing web apps before 
deploying. Uploading to my ISP to run is a PIA. I've installed VertrigoServ to 
try, but am chasing my tail around the Apache configuration.
  Is there something easier?
Just pointers to get me started would be fine.

More info.I will be migrating data base apps from MSAccess 2000. I know, I 
know, but it was free on my original Win 95 PC.
I've been programming for 50 years and have had to learn (and unlearn) a lot, 
and I'm eager to learn new stuff.

Thanks.


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

Re: Book authoring

[Peter]

On Jan 4, 9:34 am, wesley chun  wrote:
> fwiw, i've given a related talk a couple of times on this subject, the
> most recent of which was at EuroPython this 
> summer:http://ep2011.europython.eu/conference/talks/writing-books-using-pyth...
>
> the content includes a couple of the tools mentioned in this thread as
> well as some author case studies. slide deck's available there too.
>
> cheers,
> --wesley
>
> On Dec 9 2011, 7:43 am, Nick Dokos  wrote:
>
>
>
>
>
>
>
>
>
> > Grant Edwards  wrote:
> > > On 2011-12-09, Miki Tebeka  wrote:
> > > > Greetings,
>
> > > > Any recommendations for abook authoringsystem that supports the 
> > > > following:
> > > > 1. Code examples (with syntax highlighting and line numbers)
> > > > 2. Output HTML, PDF, ePub ...
> > > > 3. Automatic TOC and index
> > > > 4. Search (in HTML) - this is a "nice to have"
>
> > >http://en.wikipedia.org/wiki/Lightweight_markup_language
>
> > > I've used asciidoc extensively and reStructuredText a little. Asciidoc
> > > will produce all the formats you mentioned (though I've only refularly
> > > used HTML and PDF). reStructuredText is what's used for Python docs
> > > isn't it?
>
> > > > Can I somehow use Sphinx?
>
> > > Don't know what Sphinx is.
>
> > I think Sphinx is used for the python docs: it sits atop rST and does
> > all the transformations/processing to produce the desired output
> > (http://sphinx.pocoo.org)
>
> > > And there's always the old stand-by LaTeX, but it's a bit more
> > > heavyweight with more of a learning curve.  OTOH, it does produce
> > > text-book quality output.
>
> > There is also orgmode, which has been used for a few books
> > (http://orgmode.org). I know it does HTML and PDF (the latter through
> > latex), but I'm not sure about ePub: ISTR somebody actually did ePub for
> > his book but I don't remember details. The indexing is manual:
> > add #+index: foo entries as required.  But in general, imo, automatic
> > indexing for books sucks raw eggs (it works much better for highly
> > regular source code like the python source base).
>
> > Nick
>
> --
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> "Core Python", Prentice Hall, (c)2007,2001
> "Python Fundamentals", Prentice Hall, (c)2009
>    http://corepython.com
>
> wesley.chun : wescpy-gmail.com : @wescpy/+wescpy
> python training and technical consulting
> cyberweb.consulting : silicon valley, cahttp://cyberwebconsulting.com

My apologies, but I just read the intro - no time to watch the video,
so I am probably missing the point of your post :-)

TeX/LaTeX is open source and does an excellent job - plus you can use
your favourite editor to enter the text (I have never been able to
understand why wordprocessors have never been extended beyond the
range of simple text entry functions - most editors offer so many aids
to text entry so you would think some WPs would have taken the hint
and put some more features in!).

So does this just re-invent the wheel (so to speak)?

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

Re: Python3 on MacOsX Lion?

[Irmen de Jong]

On 2-1-2012 20:32, K Richard Pixley wrote:
> Where would I look to find the current expected status of python3 on MacOsX 
> Lion?
> 
> The distributed binaries aren't capable of allowing extensions that use gcc.
> 
> I can build the source naked, but then it lacks some libraries, notably, 
> readline.
> 
> Attempting to build the full Mac packages fails, even with the few tiny 
> patches I used
> for 2.7.2.
> 
> Is anyone working on this?  Are there pre-release patches available?
> 
> Should I be asking elsewhere?
> 
> --rich


I suggest installing it via Homebrew. Install homebrew first if you haven't 
already,
http://mxcl.github.com/homebrew/

Then,

$ brew install python3
 wait a bit...
$ python3
 ...profit!


(It's probably wise to brew install gdbm, readline, and sqlite first. These 
will then be
used by the python brew installations. If you don't, they might be unavailable 
or be the
older system-provided versions)

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

Re: MOST COMMON QUESTIONS ASKED BY NON-MUSLIMS ?????????

[gene heskett]

On Tuesday, January 03, 2012 07:27:32 PM D'Arcy Cain did opine:

> On 12-01-03 01:24 PM, gene heskett wrote:
> > The solution is to chop the link between google.groups and this list. 
> > But that subject has been declared verboten. Too much inconvenience
> > to ask the googlers to subscribe to the real list I guess.  Because
> > my spamassassin
> 
> Perhaps they just need to be reminded from time to time that many of us
> have already "chopped the link" and for us there is no Google Groups on
> this list.  I never even saw the original message because everything
> from GG goes straight to /dev/null on my system.
> 
> Now if only I could automatically kill the replies to GG messages.  :-)
> 
> P.S. if you use Spamassassin:
> :0 Hir
> 
> * ^List-Id:.*python-list.python.org
> * ^From:.*@gmail.com
> * ^Newsgroups:.*
> /dev/null

Dropped into my .procmailrc, thanks.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: 
The major advances in civilization are processes that all but wreck the
societies in which they occur.
-- A.N. Whitehead
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Newbie Help

[Ben Finney]

mixolydian  writes:

> I want to get into Python progamming for both local database
> applications and dynamic web pages. Maybe some Q&D scripts.

Welcome to the Python community. You have found a good general-purpose
programming language, and I hope you find the right help for what you're
trying to do.

> I would like some advice on:
>   1. IDEs

I advise against language-specific IDEs. You should learn at least one
general-purpose programming environment, making sure to choose one that
is:

* Free software, so that its maintenance and longevity is not at the
  mercy of any particular organisation.

* Powerful and flexible, so that it's easy for experts to make it
  support specific programming languages and tasks.

* Mature, so that it has a great deal of such support for many languages
  and tasks already written by such experts.

* Actively maintained by a vibrant and open developer community, so that
  you can be confident it will continue to adapt to changing needs.

* Cross-platform, so that you're not denied the use of any popular
  workstation OS.

For my purposes, either { GNU Screen + Bash + Emacs } or { GNU Screen +
Bash + Vim } are good choices satisfying all the above criteria. There
may be other good combinations.

>   2. GUI tools, tkinter and others

Tkinter has become much more flexible and “modern” in recent years. See
http://tkdocs.com/> for a good tutorial on using Tk for GUI design;
it focuses on Tk and presents examples in many languages, including
Python.

>   3. An integrated web server package for Win Vista

Can't help you there, I don't find Windows to meet my criteria for a
good development nor deployment environment.

> More info.I will be migrating data base apps from MSAccess 2000. I
> know, I know, but it was free on my original Win 95 PC.

You will want to learn SQL and relational databases. As a distinct task,
you *might* want to learn to operate a database server.

Python comes with SQLite included, so you can learn a functional SQL
database system without entangling it with the complications of running
a server.

Once you reach the point where a dedicated database server is needed, I
would recommend going to the best: PostgreSQL. But again, you can delay
that until after you are familiar with SQLite.

> I've been programming for 50 years and have had to learn (and unlearn)
> a lot, and I'm eager to learn new stuff.

Good hunting to you.

-- 
 \ “We can't depend for the long run on distinguishing one |
  `\ bitstream from another in order to figure out which rules |
_o__)   apply.” —Eben Moglen, _Anarchism Triumphant_, 1999 |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Newbie Help

[Steven D'Aprano]

On Tue, 03 Jan 2012 17:13:17 -0600, mixolydian wrote:

> I would like some advice on:
>   1. IDEs

Avoid them. Everything you need can be used with two applications:

- a programmer's text editor;
- a decent terminal (console) application.

A decent text editor will allow you to have multiple files open in tabs 
and rich editing tools, including completion. A decent terminal will 
allow you to have multiple sessions open, also in tabs. I have at least 
one session open to an interactive interpreter, for experimenting at the 
Python command line, and at least one other open to run my python code, 
run unit tests and doc tests, and manage source code control.

E.g. 

python -m doctest my_app.py  # run the doc tests
python -m unittest my_app_tests.py  # run a separate test suite
python my_app.py --options # and finally run the app itself

For flexibility and power, no IDE can beat the command line.

Some editors are integrated with the source control app of your choice (I 
prefer Mercurial), but I am happy to use the Mercurial command line 
tools. It's easier to find the answers to "how do I ..." when you aren't 
limited to a single editor's idiosyncrasies.

Best of all, I don't have to learn a bunch of unique IDE commands which 
don't work anywhere else. I just use my normal tools.


>   2. GUI tools, tkinter and others

tkinter is pretty much the lowest common denominator. It's good, 
especially now that it has native widgets, but if you want something 
better, you might like to try wxPython.


>   3. An integrated web server package for Win Vista 

Try cherrypy, which includes its own web server as well as a web 
framework.

http://cherrypy.org/



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

Re: python philosophical question - strong vs duck typing

[Devin Jeanpierre]

> This strikes me as petty hair-splitting.

Maybe it is! I don't know what "petty" means.

> 1. By tacking on the qualification, I was acknowledging that someone,
> somewhere, might controvert it. If you allow for arbitrary redefinitions of
> words, you could claim that any statement is an opinion. So what?

I don't know where the original definition of "strong typing" came
from. My experience has been that everyone has their own definition --
some people redefine it when faced with absurd consequences of their
original definition, but usually to something roughly similar. I
believe that people redefine it because to say your language is
"weakly typed" sounds, well, like a weakness, or like an insult. It
raises my hairs when people phrase it like that, anyway.

> 2. It ignores the context established by the OP who began with 'Let's say we
> wanted to type strongly in Python' and continued with a question about
> declarations and compilation specifically to C or C++.
>
> In that context, I think my statement qualifies as a fact.

I agree, what I said there does ignore it. This is why I made a point
of quoting you a second time, when you specifically referred to the
OP, and stating my agreement. Sorry for any misunderstanding. As far
as your correction to the OP goes, I am in favor. Aside from the small
nit that applies to a statement if you take it out of context.

> Can you give an actual example of such a definition of 'strongly typed
> object' that excludes Python objects?

I'd love to, but I neglected to above because I don't really know
where we share ideas, and I wouldn't want to jump ahead and say
something that seems outlandish. I hope I've done a decent enough job
below. Stop me if I say something you don't agree with.

Here's a short version: The term often refers to a continuum, where
some languages are "stronger" than others, but there is no objective
definition of "strong" -- it's like asking how big is "big", or how
smart is "smart". The actual choice of what continuum strength refers
to varies between people -- some specify it as "reinterpretation of
bits in memory", in which case every dynamic language in the world is
strongly typed (so I'll move on from that), or some as "implicit
conversions between types", which is iffy because any function or
overloaded operator can silently convert types (at least in Python),
meaning the language is as weak as the user (?). But they're both kind
of reasonable and held by a few people, and it's easy to see how maybe
somebody used to significantly more strict rules (OCaml, for example)
might accuse Python of not being all that strong. So you see it isn't
really a change of definition, it's a redrawing of the lines on a
continuum. The OCaml people are reasonable for saying what they say,
because their point of reference is their favorite language, just as
ours is ours. To us, maybe Haskell and OCaml are insanely
strong/"strict", to them, we're insanely weak.

Here's another take, more in line with what I really meant: the
continuums expressed above aren't universal either. IME they're chosen
by dynamic typing advocates, which are worried about code readability
and certain styles of immensely common errors that come from
lower-level languages like C. Static typing advocates (at least in the
functional programming language family) are instead concerned about
correctness. For them, type systems are a way to reduce the number of
errors in your code _in general_, not just the specific cases of type
coercion or memory-safety. In this particular sense, Python is not
very far from C -- it saves us from things that can crash the entire
process or give us incorrect results rather than alerting us of a
problem, but usually only so that we can encounter them in a more
recoverable form. For example, out-of-bounds array access can no
longer alter various parts of your stack and ruin the entire program
state, but it is still a possible error. Static typing advocates say
that strong typing can completely eliminate some types of errors, and
the sensible time to detect such errors is at compile-time.

This is absolutely an origin for the conflation of static vs strong
typing, and it's hard to differentiate them in this sense, primarily
because this notion of strong typing basically requires static typing
for powerful results. On the other hand, you can clearly have
"stronger" languages at runtime -- there are plenty of errors Python
prevents, that C does not, even though python is dynamically typed and
C is not. So Python's type system is clearly stronger than C. I hope
this illustrates that strong and static are two different things even
under this definition -- it's just that, most of the time, to really
prevent an error, you prevent it from ever happening at compile-time.

Type systems exist which are much "stronger" in what they can protect
you against. As an extreme example, one might take a dependently-typed
language. A statically dependently typed language can protec

Re: Is there anyway to selectively inherit/import a class/module?

[Steven D'Aprano]

On Tue, 03 Jan 2012 14:21:36 -0800, Peter wrote:

> I have a program that talks to a device via a serial interface.
> Structurally it looks like this:
> 
> Program A -> module B -> Serial

I don't understand what this means. Program A points to module B, which 
points to ... what is Serial? Where is it? Is it a class inside the 
module, or another module?


> I want to add a protocol layer around the serial port without modifying
> any of the modules above and I want to be able to use BOTH cases of the
> program whenever convenient, 

Where are you using them from? Program A, or another program?

I don't see any way to add the extra functionality to Program A without 
modifying Program A. But if you're okay with that, here's a way to 
conditionally define a class to use:

# inside Program A
import moduleB

if condition:
Serial = moduleB.Serial  # I assume moduleB has a Serial class
else:
class Serial(moduleB.Serial):  # subclass
def mymethod(self):
pass


connection = Serial(...)



> so at first it seemed like a simple case of
> sub-classing the Serial class and then (this is the problem) somehow use
> either the original serial class definition when I wanted the original
> program functionality or the new class when I wanted the extra layer
> present.

No problem. Here's another way to do it:

from moduleB import Serial as SimpleSerial
class ComplexSerial(SimpleSerial):
...

And now you can use both at the same time.



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

Re: Python education survey

[Steven D'Aprano]

On Tue, 03 Jan 2012 04:33:45 -0800, Eelco wrote:

>> Why do people use pretty when we already have words that carry more
>> specific meaning? Because they are lazy! And laziness begets stupidity.
> 
> No, that would be because they are not autistic. Most people like having
> a repertoire of words with subtly different meanings in their natural
> language, because there is a demand for this semantic richness.

+1 QOTW


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

Re: Spamming PyPI with stupid packages

[Steven D'Aprano]

On Tue, 03 Jan 2012 05:08:47 -0800, Ethan Furman wrote:

[...]
>> "maybe policing uploads is worse than cluttering PyPI's disk space and
>> RSS feed with dumb 1 KB packages." (Matt Chaput)
>> 
>> I'd drop the "maybe".
> 
> It's hard enough finding what one wants without having to wade through
> crap.  PyPI is not the place for it.

I agree. But who gets to choose which packages are "serious" enough to 
deserve to be on PyPI? Or good enough?

The cost of allowing anyone the freedom to publish their work is that 
some published work will be crap.

Besides, I find it hard to believe that the search facilities on PyPI are 
so bad that there would be any searches that come up with "girlfriend.py" 
or "car.py" as false positives.

Seriously, the over-reaction here is something that has to be seen to be 
believed. The original complaint is over a couple of entries in an RSS 
feed and showing up on the front page of PyPI, perhaps a dozen words in 
total. The reaction has been thousands of words arguing back and forth.


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

Re: Spamming PyPI with stupid packages

[Steven D'Aprano]

On Wed, 04 Jan 2012 08:57:59 +1100, Ben Finney wrote:

> Steven D'Aprano  writes:
> 
>> The joke cuts both ways.
> 
> This is the Just World fallacy: you're implying that, because the same
> joke can be applied equally well to women or men, that therefore it is
> equally harmful. The fallacy is to ignore the fact that the playing
> field is not level.

I'm not ignoring the fact of an unequal playing field. (The playing field 
is uneven in different directions in different places.)


> Yes, that same joke can semantically be applied equally to men. But it
> is disproportionately harmful to women, 

You're making an assumption there that I don't accept. There is no 
evidence that it is harmful to *anyone*, men or women.

And not just because "it's only a joke" -- jokes are a wonderfully 
powerful weapon, and like all weapons, they can be used for good or evil. 
E.g. the Klu Klux Klan lost a lot of influence when the US media (and in 
particular the Superman television series) made them into a laughing 
stock. On the flip-side, Irish jokes have been both a reaction to Irish 
terrorism and a way of depowering the Irish.

But if jokes are weapons, this particular joke is not only a water 
pistol, but it's a *broken* water pistol.

There are barriers to women becoming programmers. Some of those barriers 
come from men, others come from other women, and some are internal to the 
specific woman in question. One might even be able to list some of those 
barriers. But if you think that it is self-evident that childish jokes 
about working hard in order to attract a girlfriend is one of those 
barriers, then I have to disagree strongly.

[...]
> Apologetics defending sexist jokes against women

In what way is this a sexist joke against women?

Normally, one can point out the victim of sexist or racist jokes: it 
makes a class of people out to be a laughing stock, incompetent or stupid 
or wicked. That is not the case here, unless we think that preferring a 
hard-worker and good provider over a lazy deadbeat is a sign of moral 
degeneracy (that is, "gold-digger" versus "wants the best for herself and 
her children").


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

Re: Spamming PyPI with stupid packages

[Ben Finney]

Steven D'Aprano  writes:

> On Wed, 04 Jan 2012 08:57:59 +1100, Ben Finney wrote:
>
> > Steven D'Aprano  writes:
> > 
> >> The joke cuts both ways.
> > 
> > The fallacy is to ignore the fact that the playing field is not
> > level.
>
> I'm not ignoring the fact of an unequal playing field. (The playing
> field is uneven in different directions in different places.)

Your “the joke cuts both ways” is of no matter, then.

> > Yes, that same joke can semantically be applied equally to men. But
> > it is disproportionately harmful to women,
>
> You're making an assumption there that I don't accept. There is no
> evidence that it is harmful to *anyone*, men or women.

It objectifies women. If you can't see how that's harmful to women, I
haven't the stamina to educate you.

-- 
 \   “We spend the first twelve months of our children's lives |
  `\  teaching them to walk and talk and the next twelve years |
_o__)   telling them to sit down and shut up.” —Phyllis Diller |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Spamming PyPI with stupid packages

[Steven D'Aprano]

On Wed, 04 Jan 2012 12:54:09 +1100, Ben Finney wrote:

> Steven D'Aprano  writes:
[...]
>> You're making an assumption there that I don't accept. There is no
>> evidence that it is harmful to *anyone*, men or women.
> 
> It objectifies women.

So you claim.

> If you can't see how that's harmful to women, I
> haven't the stamina to educate you.

Since you can't or won't persuade me (and anyone else reading) that this 
sort of joke is harmful, does that mean that you will stop claiming that 
it is harmful?

Or do you expect us to just take your word for it and stop questioning 
you?


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

Re: python philosophical question - strong vs duck typing

[alex23]

On Jan 4, 6:38 am, Terry Reedy  wrote:
> Shredskin compiles a subset of
> Python, or a subset of usages, to C, with similar benefits.

That is, of course, 'Shedskin' and 'C++' :)

+1 for either Cython or Shedskin as your next step for more performant
Python.
-- 
http://mail.python.org/mailman/listinfo/python-list