Re: OT: This Swift thing
Am 06.06.14 13:20, schrieb Alain Ketterlin: Chris Angelico writes: It's impossible to accidentally call a base class's method when you ought to have called the overriding method in the subclass, which is a risk in C++ [2]. I don't how this can happen in C++, unless you actually have an instance of the base class. Anyway, I didn't mention C++. A special, but important case of this is inside the constructor. Until you exit the constructor, C++ treats the object as not fully constructed, and if you call a virtual method there, it calls the method of the base class. http://www.parashift.com/c++-faq/calling-virtuals-from-ctors.html The answer is, of course, to create a *separate* init function in addition to the constructor and to require the user of the class to call it after the constructor, or to hide the real constructor away and require the user to call a factory function instead. I love C++. (seriously, but not /that/ part) Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
Sturla Molden writes: > Alain Ketterlin wrote: >> Sturla Molden writes: >> >>> Alain Ketterlin wrote: >>> Many of these students suggest Python as the development language (they learned it and liked it), and the suggestion is (almost) always rejected, in favor of Java or C# or C/C++. >>> >>> And it was almost always the wrong decision... >> >> I think they know better than you and me. > > Now it's my turn to say "oh, come on". Those who make these decisions have > likely never written a line of code in their life. This totally contradicst my experience. I've heard horror stories like everybody else, but I just have been lucky enough to work with people that very seriously evaluate their engineering decisions. -- Alain. -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On 07/06/2014 09:20, Alain Ketterlin wrote: Sturla Molden writes: Alain Ketterlin wrote: Sturla Molden writes: Alain Ketterlin wrote: Many of these students suggest Python as the development language (they learned it and liked it), and the suggestion is (almost) always rejected, in favor of Java or C# or C/C++. And it was almost always the wrong decision... I think they know better than you and me. Now it's my turn to say "oh, come on". Those who make these decisions have likely never written a line of code in their life. This totally contradicst my experience. I've heard horror stories like everybody else, but I just have been lucky enough to work with people that very seriously evaluate their engineering decisions. -- Alain. Clearly manpower isn't an issue. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: http.server.BaseHTTPRequestHandler basic auth logout? Django authentication system for REST interface?
On Sat, Jun 7, 2014 at 4:23 PM, dieter wrote: > Dan Stromberg writes: > >> I have some code for a web server. Right now, it uses >> BaseHTTPRequestHandler with Basic Auth, but we want to be able to log >> out, and there doesn't appear to be a general way to log out of >> something using Basic Auth, short of turning to unportable JavaScript. > > You can't: With "Basic Auth", the login is handled by the browser > (and not the server). This implies, that you must tell the browser > to logout (and not the server). There is no "standard way" to > tell the browser to logout. That said, though, it's quite common for browsers to discard the auth (thus effectively logging out) if given another 401 Unauthorized response. So you can generally send that back and expect it to be a "logout" page. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
Mark Lawrence writes: > On 07/06/2014 09:20, Alain Ketterlin wrote: >> Sturla Molden writes: >> Many of these students suggest Python as the >> development language (they learned it and liked it), and the suggestion >> is (almost) always rejected, in favor of Java or C# or C/C++. > > And it was almost always the wrong decision... I think they know better than you and me. >>> >>> Now it's my turn to say "oh, come on". Those who make these decisions have >>> likely never written a line of code in their life. >> >> This totally contradicst my experience. I've heard horror stories like >> everybody else, but I just have been lucky enough to work with people >> that very seriously evaluate their engineering decisions. > Clearly manpower isn't an issue. No. Cost is the issue (development, maintenance, operation, liability...). Want an example? Here is one: http://tech.slashdot.org/story/14/06/06/1443218/gm-names-and-fires-engineers-involved-in-faulty-ignition-switch -- Alain. -- https://mail.python.org/mailman/listinfo/python-list
strange behaivor of nested function
here is code
def make():
def jit(sig):
def wrap(function):
sig=sig[0] # unbound local error, if change to sig='' would be just
fine
return function
return wrap
return jit
jit=make()
@jit('')
def f():
pass
It is strange that the interpreter complain about unbound local error.
please give me some suggestion, thanks!
Ps: I am using python 2.7
Liu Zhenhai
发自我的 iPhone
--
https://mail.python.org/mailman/listinfo/python-list
Re: strange behaivor of nested function
On Sat, Jun 7, 2014 at 9:17 PM, 1989lzhh <1989l...@gmail.com> wrote:
> def make():
> def jit(sig):
> def wrap(function):
> sig=sig[0] # unbound local error, if change to sig='' would be
> just fine
> return function
> return wrap
> return jit
> jit=make()
> @jit('')
> def f():
> pass
>
> It is strange that the interpreter complain about unbound local error.
> please give me some suggestion, thanks!
> Ps: I am using python 2.7
It's quite simple. You're assigning to the name 'sig' inside the
function 'wrap', which means that - in the absence of a declaration -
'sig' is a local name. But before you assign anything to it, you first
try to reference it, by subscripting it (sig[0]). Python doesn't have
a rule about pulling something in from another scope at the same time
as making it local (some languages do, and it's rather handy, but it
can only work with variable declarations), so what you're attempting
to do there simply won't work.
But it seems a little odd anyway. Why do you take the first element of
sig every time the inner function is called? Surely you want to do
that just once?
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
In article <87zjhpm8q7@dpt-info.u-strasbg.fr>, Alain Ketterlin wrote: > Sturla Molden writes: > > > Alain Ketterlin wrote: > >> Sturla Molden writes: > >> > >>> Alain Ketterlin wrote: > >>> > Many of these students suggest Python as the > development language (they learned it and liked it), and the suggestion > is (almost) always rejected, in favor of Java or C# or C/C++. > >>> > >>> And it was almost always the wrong decision... > >> > >> I think they know better than you and me. > > > > Now it's my turn to say "oh, come on". Those who make these decisions have > > likely never written a line of code in their life. > > This totally contradicst my experience. I've heard horror stories like > everybody else, but I just have been lucky enough to work with people > that very seriously evaluate their engineering decisions. You are lucky indeed. Trust me, in big companies, technical decisions are often made by people who are not using the technology. -- https://mail.python.org/mailman/listinfo/python-list
Re: strange behaivor of nested function
On Sat, 07 Jun 2014 19:17:23 +0800, 1989lzhh wrote: > here is code > > def make(): > def jit(sig): > def wrap(function): > sig=sig[0] # unbound local error You are saying: "sig is a local variable. Assign sig to the value of sig[0]." But what is sig? You've said it is a local variable, and at this point it doesn't have a value yet. Lua allows you to do this: sig = sig[0] will look up a global sig and assign it to the local sig first, but that can be confusing and Python doesn't do that. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
In article , Dennis Lee Bieber wrote: > On 07 Jun 2014 04:57:19 GMT, Steven D'Aprano > declaimed the following: > > > > >Swift is intended as a new generation *systems language*. The old > >generation of systems languages are things like C, Objective-C, C#, C++, > >Java, Pascal, Algol, and so forth. The new generation are intended to > >fulfil the same niches, but to have syntax and usability closer to that > >of scripting languages. Languages like Go, Rust, Ceylon, and now Swift. > > > Pascal as a systems language? We must have major differences what > constitutes a systems language then... The original MacOS was written in Pascal (both applications and kernel). Being able to touch memory locations or registers requires no more than a few short glue routines written in assembler. -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
In article , Dennis Lee Bieber wrote: > On Sat, 07 Jun 2014 08:52:36 -0400, Roy Smith declaimed the > following: > > > >You are lucky indeed. Trust me, in big companies, technical decisions > >are often made by people who are not using the technology. > > Or influenced by someone familiar with some tech and having a big > ego... > > Many years ago, in a company to remain nameless, I was in a department > with ~130 programmers distributed among 3-4 main subsystems (batch analysis > [aka, post-processing of the daily tapes], planning [generating the > schedule for the next day], and real-time [operations using the schedule]). > The real-time group was 15-30 people using Macro-11 (PDP-11s if that dates > things). The rest of the department was pretty much all skilled VAX > FORTRAN-77. > > The time came to port real-time from PDP-11 to a VAX system. A small > study was performed to determine what language would be used. Very small > study -- I think it was restricted to the 30 RT folks; I only learned of > the result after a choice had been made. > > The candidates: VAX-11 Assembly, F77, C, Pascal. What was wrong with just running the original pdp-11 binaries on the VAX in compatibility mode? :-) -- https://mail.python.org/mailman/listinfo/python-list
Science in Islam
Science in Islam "We (God) shall show them Our signs in the Universe and within themselves, until it becomes clear to them that this is the Truth." Quran 41:53 The Quran, the book of Islam, is the final book of revelation from God to humanity and the last in the line of revelations given to the Prophets. Although the Quran (revealed over 1400 years ago), is not primarily a book of science, it does contain scientific facts that have only been discovered recently through the advancement of technology and scientific knowledge. Islam encourages reflection and scientific research because understanding the nature of creation enables people to further appreciate their Creator and the extent of His power and wisdom. The Quran was revealed at a time when Science was primitive; there were no telescopes, microscopes or anything close to today's technology. People believed that the sun orbited the earth and the sky was held up by pillars at the corners of a flat earth. Against this backdrop the Quran was revealed, containing many scientific facts on topics ranging from astronomy to biology, geology to zoology. Some of the many scientific facts found in the Quran include: Fact #1 - Origin of Life "And We (God) made every living thing from water. Will they not believe?" Quran 21:30 Water is pointed out as the origin of all life. All living things are made of cells and we now know that cells are mostly made of water. This was discovered only after the invention of the microscope. In the deserts of Arabia, it would be inconceivable to think that someone would have guessed that all life came from water. Fact #2 - Human Embryonic Development God speaks about the stages of man's embryonic development: "We (God) created man from an extract of clay. Then We made him as a drop in a place of settlement, firmly fixed. Then We made the drop into an alaqah [leech, suspended thing, and blood clot], then We made the alaqah into a mudghah [chewed substance]..." Quran, 23:12-14 The Arabic word "alaqah" has three meanings: a leech, a suspended thing and a blood clot. "Mudghah" means a chewed substance. Embryology scientists have observed that the usage of these terms in describing the formation of the embryo is accurate and in conformity with our current scientific understanding of the development process. Little was known about the staging and classification of human embryos until the twentieth century, which means that the descriptions of the human embryo in the Quran cannot be based on scientific knowledge from the seventh century. Fact #3 - Expansion of the Universe At a time when the science of Astronomy was still primitive, the following verse in the Quran was revealed: "And the heaven We (God) constructed with strength, and indeed, We (God) are [its] expander." Quran 51:47 One of the intended meanings of the above verse is that God is expanding the universe (i.e. heavens). Other meanings are that God provides for, and has power over, the universe - which are also true. The fact that the universe is expanding (e.g. planets are moving further away from each other) was discovered in the last century. Physicist Stephen Hawking in his book 'A Brief History of Time' writes, "The discovery that the universe is expanding was one of the great intellectual revolutions of the twentieth century." The Quran alludes to the expansion of the universe even before the invention of the telescope! Fact #4 - Iron Sent Down Iron is not natural to earth, as it came to this planet from outer space. Scientists have found that billions of years ago, the earth was struck by meteorites which were carrying iron from distant stars which had exploded. "We sent down iron with its great inherent strength and its many benefits for humankind." Quran 57:25 God uses the words 'sent down'. The fact that iron was sent down to earth from outer space is something which could not be known by the primitive science of the seventh century. Fact #5 - Sky's Protection The sky plays a crucial role in protecting the earth and its inhabitants from the lethal rays of the sun, as well as the freezing cold of space. God asks us to consider the sky in the following verse: "We (God) made the sky a protective ceiling. And yet they are turning away from Our signs!" Quran 21:32 The Quran points to the sky's protection as a sign of God, protective properties which were discovered by scientific research conducted in the twentieth century. Fact #6 - Mountains God draws our attention to an important characteristic of mountains: "Did We not make the earth a resting place, and the mountains as stakes?" Quran 78:6-7 The Quran accurately describes the deep roots of mountains by using the word "stakes". Mount Everest, for example, has an approximate height of 9km above ground, while its root is deeper than 125km! The fact that mountains have deep 'stake'-like roots was not known until after the development of the theory of plate t
Re: OT: This Swift thing
On 06/07/2014 09:23 AM, Dennis Lee Bieber wrote: > On 07 Jun 2014 04:57:19 GMT, Steven D'Aprano > declaimed the following: > >> >> Swift is intended as a new generation *systems language*. The old >> generation of systems languages are things like C, Objective-C, C#, C++, >> Java, Pascal, Algol, and so forth. The new generation are intended to >> fulfil the same niches, but to have syntax and usability closer to that >> of scripting languages. Languages like Go, Rust, Ceylon, and now Swift. >> > Pascal as a systems language? We must have major differences what > constitutes a systems language then... > > Native Pascal had no features to support hitting the hardware or > arbitrary memory addresses/registers. It was a candidate for an > applications language (though even that always felt a stretch to me; as a > teaching language for structured programming it was ideal, though). Try > writing a serial port driver for a memory mapped I/O system using pure > Pascal. Technically C doesn't either, except via subroutines in libc, though C does have pointers which would be used to access memory. In the old MS DOS days, C would embed assembly to call interrupts and set up interrupt tables, etc. As someone else mentioned recently, Pascal was used as the system language on Mac computers for many years. -- https://mail.python.org/mailman/listinfo/python-list
How to use imported function to get current globals
Here is the code m1.py def f(): print globals() m2.py from m1 import f f()# how to get current module's globals? -- https://mail.python.org/mailman/listinfo/python-list
Re: How to use imported function to get current globals
On Sat, Jun 7, 2014 at 11:40 AM, 1989lzhh <1989l...@gmail.com> wrote: > Here is the code > m1.py > def f(): > print globals() > > m2.py > from m1 import f > f()# how to get current module's globals? Evaluate globals() in the current module and pass the resulting dict in as a parameter: # m1.py def f(globals): print globals # m2.py from m1 import f f(globals()) There's a code smell here, though. If your function really needs to interact with globals from other modules, then those should probably not be globals in the first place. More likely they should be attributes of objects that can be easily passed around. -- https://mail.python.org/mailman/listinfo/python-list
Re: Regarding Python official website
The Job board. It has been on hold for quite some time. -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
In article , Michael Torrie wrote: > Technically C doesn't [have features to support hitting the hardware] > either, except via subroutines in libc, though C does have pointers > which would be used to access memory. Several language constructs in C are there specifically to diddle bits in hardware. Bit fields were in the earliest implementations of the language to allow you to address individual bit control and status bits in memory-mapped device controllers. The volatile keyword is there to deal with bits which change value on their own (as hardware status registers do). And, why do you need a library routine to touch a memory location, when you can just dereference an integer? :-) -- https://mail.python.org/mailman/listinfo/python-list
Token-based authentication (was http.server.BaseHTTPRequestHandler basic auth logout? Django authentication system for REST interface?)
On Jun 6, 2014 6:30 PM, "Roy Smith" wrote: > We would have to keep state on the server side about every extant valid > token (but then again, we need to do that now, for each session). If you didn't want to have to manage such state server side, you could opt to use JWTs (http://datatracker.ietf.org/wg/jose/). A number of auth providers (including Microsoft and Google) are moving to using these as well. Of course, /some/ server side state would have to be managed to deal with invalidation or any other mutable data that doesn't belong in a token, but it's generally minimal. [Shameless plug] I've implemented a subset of the algorithms for both JWE and JWSs as a part of https://pypi.python.org/pypi/jose. -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On 06/07/2014 12:11 PM, Roy Smith wrote: > Several language constructs in C are there specifically to diddle bits > in hardware. Bit fields were in the earliest implementations of the > language to allow you to address individual bit control and status bits > in memory-mapped device controllers. The volatile keyword is there to > deal with bits which change value on their own (as hardware status > registers do). > > And, why do you need a library routine to touch a memory location, when > you can just dereference an integer? :-) Which of course, technically, Pascal has too. But memory addressing is only half the story. You still need interrupts and ioctl access, both of which happen via assembly instructions that libc exposes via a standard C subroutine interface. Really any language can access hardware this way. Whether it's MicroPython on an embedded system, or BASIC on a pic. The lines are being blurred. -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
In article , Michael Torrie wrote: > On 06/07/2014 12:11 PM, Roy Smith wrote: > > Several language constructs in C are there specifically to diddle bits > > in hardware. Bit fields were in the earliest implementations of the > > language to allow you to address individual bit control and status bits > > in memory-mapped device controllers. The volatile keyword is there to > > deal with bits which change value on their own (as hardware status > > registers do). > > > > And, why do you need a library routine to touch a memory location, when > > you can just dereference an integer? :-) > > Which of course, technically, Pascal has too. > > But memory addressing is only half the story. You still need interrupts > and ioctl access, both of which happen via assembly instructions that > libc exposes via a standard C subroutine interface. Well, on a machine where all I/O is memory mapped, it's really 3/4 of the story, but I get your point. -- https://mail.python.org/mailman/listinfo/python-list
Re: Regarding Python official website
On Sat, Jun 7, 2014 at 1:12 AM, Aseem Bansal wrote: > The Python website is undergoing an overhaul for better looks. Is there > anything like a forum where it is being discussed. I mean where the schedule > for this is being maintained or the same is being discussed? https://github.com/python/pythondotorg/ Kushal -- CPython Core Developer http://fedoraproject.org http://kushaldas.in -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
On Sat, Jun 7, 2014 at 12:45 AM, jongiddy wrote:
> The language D has a feature called Uniform Function Call Syntax, which
> allows instance methods to be resolved using function calls.
>
> In Python terms, the call:
>
> x.len()
>
> would first check if 'x' has a method 'len', and would then look for a
> function 'len', passing 'x' as the first argument.
>
> The big wins are:
>
> - the ability to override functions with more optimal class-specific
> implementations. (Of course, len() is a bad example, since we already have a
> way to override it, but there are other functions that do not have a special
> method).
>
> - the readability of a.b().c().d() vs c(a.b()).d()
>
> Here's a few links discussing the feature in D:
> - First, a fairly gentle "this is cool" post:
> http://www.kr41.net/2013/08/27/uniform_function_call_syntax_in_d.html
> - Second, an article from the Walter Bright, the creator of D:
> http://www.drdobbs.com/cpp/uniform-function-call-syntax/232700394
>
> Has this been discussed or proposed before? I found PEP's 443 and 3124, which
> provide a form of function overloading, but not reordering.
It's a nice feature in a statically typed language, but I'm not sure
how well it would work in a language as dynamic as Python. There are
some questions that would need to be addressed.
1) Where should the function (or perhaps callable) be looked for? The
most obvious place is the global scope. I think it would be a bit too
far-reaching and inconsistent with other language features to reach
directly inside imported modules (not to mention that it could easily
get to be far too slow in a module with lots of imports). As a result
it would have to be imported using the "from module import function"
syntax, rather than the somewhat cleaner "import module" syntax.
While there's nothing wrong with such imports, I'm not sure I like the
thought of the language encouraging them any more than necessary.
Probably local (and by extension nonlocal) scoping is fine also. This
makes perfect sense to me:
def some_function(x):
def my_local_extension_method(self): return 42
print(x.my_local_extension_method())
2) What about getattr and hasattr? If I call hasattr(x,
"some_method"), and x has no such attribute, but there is a function
in the global scope named "some_method", should it return True? I
think the answer is no, because that could mess with duck typing. Say
I have a function that checks the methods of some object that was
passed in, and it then passes that object on to some other function:
def gatekeeper_for_f(x):
# f behaves badly if passed an x without a key_func,
# so verify that it has one.
if not hasattr(x, 'key_func'):
raise TypeError("x has no key_func")
else:
return f(x)
Okay, so suppose we pass in to gatekeeper_for_f a non-conformant
object, but there happens to be a key_func in our global scope, so
hasattr returns True. Great! gatekeeper_for_f can call x.key_func().
But that doesn't mean that *f* can call x.key_func(), if it happened
to be defined in a different global scope.
If we instead have hasattr return False though, and have getattr raise
an exception, then we have this very magical and confusing
circumstance where getattr(x, 'method') raises an exception but
x.method does not. So I don't think that's really a good scenario
either.
Also the idea makes me nervous in the thought that an incorrect
attribute access could accidentally and somewhat randomly pick up some
object from the environment. In statically typed languages this isn't
a huge concern, because the extension method has to take an
appropriately typed object as its first argument (and in C# it even
has to be explicitly marked as an extension method), so if you resolve
an extension method by accident, at least it will be something that
makes sense as a method. Without the static typing you could
mistakenly pick up arbitrary functions that have nothing at all to do
with your object.
But if you want to experiment with the idea, here's a (lightly tested)
mixin that implements the behavior:
import inspect
import types
class ExtensionMethodMixin:
def __getattr__(self, attr):
parent_frame = inspect.currentframe().f_back
if parent_frame:
try:
func = parent_frame.f_locals[attr]
except KeyError:
func = parent_frame.f_globals.get(attr)
if callable(func):
try:
__get__ = func.__get__
except AttributeError:
return types.MethodType(func, self)
else:
return __get__(self, type(self))
return super().__getattr__(attr)
--
https://mail.python.org/mailman/listinfo/python-list
Re: os.startfile hanging onto the launched app, or my IDE?
On 06/06/2014 21:34, Josh English wrote: I have been using os.startfile(filepath) to launch files I've created in Python, mostly Excel spreadsheets, text files, or PDFs. When I run my script from my IDE, the file opens as I expect. But if I go back to my script and re-run it, the external program (either Excel, Notepad, or Acrobat Reader) closes all windows and restarts the program. This can, unfortunately, close other files I am working on and thus I lose all my changes to those files. This is happening on Windows 7. I am not sure if it is Python (2.7.5) or my IDE (PyScripter 2.5.3). It seems like Python or the IDE is keeping track of things created by the os.startfile call, but the docs imply this doesn't happen. Is this a quirk of os.startfile? Is there a cleaner way to get Windows to open files without tying back to my program? I'm not 100% sure what your scenario is, but you can certainly help yourself and us by running the same test on the raw interpreter and then under PyScripter to determine if the behaviour is to do with IDLE or with Python itself. My half-guess is that PyScripter starts a new process to run your code, possibly killing any pre-existing process first. That's if I've understood the situation you're describing. Could you come back with a little more detail? Specifically: whether what you're seeing happens only from within PyScripter, or only not from within PyScripter, or something else? TJG -- https://mail.python.org/mailman/listinfo/python-list
Re: How to use imported function to get current globals
On Sun, Jun 8, 2014 at 3:40 AM, 1989lzhh <1989l...@gmail.com> wrote: > Here is the code > m1.py > def f(): > print globals() > > m2.py > from m1 import f > f()# how to get current module's globals? As Ian said, you almost certainly do not want to do this. But if you have a solid use-case that involves finding the caller's globals, you can do it (in CPython - no idea about other Pythons) with the backtrace. Normally, passing dictionaries around is going to be MUCH more useful. (And probably not actually globals(), you almost never want to use that.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How to use imported function to get current globals
On 6/7/14 1:40 PM, 1989lzhh wrote: Here is the code m1.py def f(): print globals() m2.py from m1 import f f()# how to get current module's globals? Looking at the code you have posted in your two messages so far, it seems like you are building something very interesting and ambitious. Do you mind talking a bit about what it is? -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Automating windows media player on win7
On 2014-06-06 14:39, Deogratius Musiige wrote:
Thanks a lot mate.
You just made my day.
I have looked around the net but cannot find the controls available.
I would like to be able to:
- get current playing track
- get wmplayer state (playing/paused/stopped)
- get the selected sound device
[snip]
Here's a bit more. Note how it seems to need short sleeps after certain
actions (I don't know why!):
#! python2.7
# -*- coding: utf-8 -*-
import pywintypes
from win32com.client import Dispatch
from time import sleep
tunes = ["./plays.wav", "./plays.wav", "./plays.wav"] # Whatever
mp = Dispatch("WMPlayer.OCX")
for name in tunes:
tune = mp.NewMedia(name)
mp.CurrentPlaylist.AppendItem(tune)
mp.Controls.Play()
sleep(0.25)
for i in range(len(tunes)):
print "Current tune is", mp.Controls.CurrentItem.Name
print 'Playing current tune'
mp.Controls.PlayItem(mp.Controls.CurrentItem)
print 'mp.Status says', mp.Status
sleep(5)
print 'Pausing'
mp.Controls.Pause()
print 'mp.Status says', mp.Status
sleep(2)
print 'Resuming'
mp.Controls.Play()
print 'mp.Status says', mp.Status
sleep(5)
mp.Controls.Next()
sleep(0.25)
mp.Controls.Stop()
--
https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On Sat, 07 Jun 2014 11:13:42 -0400, Dennis Lee Bieber wrote: > About a decade later, said manager retired and confessed that the choice > of Pascal was a mistake There's Pascal and there's Pascal. Standard Pascal, I admit, is woefully unsuitable for real world work. But Pascal with suitable extensions was good enough for the first 6 generations of the Macintosh operating system and key applications, at a time when *nobody* was even coming close to doing what the Mac was capable of. (Admittedly, a certain number of the core OS libraries, most famously Quickdraw, were handwritten in assembly by a real genius.) By the mid-80s, Apple's SANE (Standard Apple Numeric Environment) was quite possibly the best environment for doing IEEE-754 numeric work anywhere. But of course, Macintoshes were toys, right, and got no respect, even when the Mac G4 was the first PC powerful enough to be classified by US export laws as a supercomputer. [Disclaimer: Pascal on the Mac might have been far ahead of the pack when it came to supporting IEEE-754, but it didn't have the vast number of (variable-quality) Fortran libraries available on other systems. And while it is true that the G4 was classified as a supercomputer, that was only for four months until the Clinton administration changed the laws. Apple, of course, played that for every cent of advertising as it could.] -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: try/except/finally
On 06/06/2014 11:22 AM, Ned Batchelder wrote: On 6/6/14 1:47 PM, Frank B wrote: Ok; thanks for the underscore and clarification. Just need to adjust my thinking a bit. Did this come up in real code? I've seen this point about finally/return semantics a number of times, but haven't seen real code that needed adjusting based on it. I don't remember if I almost had this in real code or if I learned about it first, but it can definitely be a gotcha. It seems to me that if the try block exits with an explicit return, and then the finally block exits with an explicit return, some kind of error ought to be raised. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On Sat, 07 Jun 2014 14:11:27 -0400, Roy Smith wrote: > And, why do you need a library routine to touch a memory location, when > you can just dereference an integer? :-) And in one sentence we have an explanation for 90% of security vulnerabilities before PHP and SQL injection attacks... C is not a safe language, and code written in C is not safe. Using C for application development is like shaving with a cavalry sabre -- harder than it need be, and you're likely to remove your head by accident. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: try/except/finally
On Sun, Jun 8, 2014 at 8:49 AM, Ethan Furman wrote: > I don't remember if I almost had this in real code or if I learned about it > first, but it can definitely be a gotcha. It seems to me that if the try > block exits with an explicit return, and then the finally block exits with > an explicit return, some kind of error ought to be raised. I'd go a little simpler: A return statement inside a finally block is code smell. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
In article <5393a264$0$29988$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano wrote: > On Sat, 07 Jun 2014 14:11:27 -0400, Roy Smith wrote: > > > And, why do you need a library routine to touch a memory location, when > > you can just dereference an integer? :-) > > And in one sentence we have an explanation for 90% of security > vulnerabilities before PHP and SQL injection attacks... > > C is not a safe language, and code written in C is not safe. Using C for > application development is like shaving with a cavalry sabre -- harder > than it need be, and you're likely to remove your head by accident. I never claimed C was a safe language. I assume you've seen the classic essay, http://www-users.cs.york.ac.uk/susan/joke/foot.htm ? And, no, I don't think C is a good application language (any more). When it first came out, it was revolutionary. A lot of really amazing application software was written in it, partly because the people writing in it were some of the smartest guys around. But, that was 40 years ago. We've learned a lot about software engineering since then. We've also got machines that are so fast, it's not longer critical that we squeeze out every last iota of performance. Oh, but wait, now we're trying to do absurd things like play full-motion video games on phones, where efficiency equates to battery life. Sigh. -- https://mail.python.org/mailman/listinfo/python-list
Re: try/except/finally
In article , Chris Angelico wrote: > A return statement inside a finally block is code smell. Not to my nose. It seems like a perfectly reasonable thing to do. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to use imported function to get current globals
发自我的 iPhone > 在 Jun 8, 2014，4:52，Chris Angelico 写道： > >> On Sun, Jun 8, 2014 at 3:40 AM, 1989lzhh <1989l...@gmail.com> wrote: >> Here is the code >> m1.py >> def f(): >>print globals() >> >> m2.py >> from m1 import f >> f()# how to get current module's globals? > > As Ian said, you almost certainly do not want to do this. But if you > have a solid use-case that involves finding the caller's globals, you > can do it (in CPython - no idea about other Pythons) with the > backtrace. Could you give an example ? I do want to get the caller's globals, so I can expose something into current module implicitly. Thanks! Liu zhenhai > > Normally, passing dictionaries around is going to be MUCH more useful. > (And probably not actually globals(), you almost never want to use > that.) > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On Sun, Jun 8, 2014 at 10:09 AM, Roy Smith wrote: > We've also got machines that are so fast, it's not longer critical that > we squeeze out every last iota of performance. Oh, but wait, now we're > trying to do absurd things like play full-motion video games on phones, > where efficiency equates to battery life. Sigh. Efficiency will never stop being important. Efficiency will also never be the one most important thing. No matter how much computing power changes, those statements are unlikely to be falsified... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How to use imported function to get current globals
On Sun, Jun 8, 2014 at 10:28 AM, 1989lzhh <1989l...@gmail.com> wrote: > > > 发自我的 iPhone > >> 在 Jun 8, 2014，4:52，Chris Angelico 写道： >> >>> On Sun, Jun 8, 2014 at 3:40 AM, 1989lzhh <1989l...@gmail.com> wrote: >>> Here is the code >>> m1.py >>> def f(): >>>print globals() >>> >>> m2.py >>> from m1 import f >>> f()# how to get current module's globals? >> >> As Ian said, you almost certainly do not want to do this. But if you >> have a solid use-case that involves finding the caller's globals, you >> can do it (in CPython - no idea about other Pythons) with the >> backtrace. >Could you give an example ? I do want to get the caller's globals, so I > can expose something into current module implicitly. Thanks! Frankly, no. I don't want to encourage implicitly exposing something like that! Why do you want that, rather than something explicit and clear? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
Michael Torrie wrote: Technically C doesn't either, except via subroutines in libc, though C does have pointers which would be used to access memory. The Pascal that Apple used had a way of casting an int to a pointer, so you could do all the tricks you can do with pointers in C. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: try/except/finally
On 08/06/2014 01:12, Roy Smith wrote: In article , Chris Angelico wrote: A return statement inside a finally block is code smell. Not to my nose. It seems like a perfectly reasonable thing to do. I agree, the code smell is the return in the except block. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
Dennis Lee Bieber wrote: Not "standard" Pascal... It had pointer types, but no means to "stuff" an integer into the pointer variable in order to dereference it as a memory address... Although most implementations would let you get the same effect by abusing variant records (the equivalent of a C union). What is an interrupt -- typically a handler (function) address stored in a fixed location used by the CPU when an external hardware signal goes high... Nothing prevents one from writing that handler in C and using C's various casting operations to stuff it into the vector memory. Most CPU architectures require you to use a special "return from interrupt" instruction to return from a hardware interrupt handler. So you need at least a small assembly language stub to call a handler written in C, or a C compiler with a non-standard extension to generate that instruction. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
Ian Kelly wrote: It's a nice feature in a statically typed language, but I'm not sure how well it would work in a language as dynamic as Python. Also it doesn't sit well with Python's "one obvious way to do it" guideline, because it means there are *two* equally obvious ways to call a function. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: try/except/finally
In article , Mark Lawrence wrote: > On 08/06/2014 01:12, Roy Smith wrote: > > In article , > > Chris Angelico wrote: > > > >> A return statement inside a finally block is code smell. > > > > Not to my nose. It seems like a perfectly reasonable thing to do. > > > > I agree, the code smell is the return in the except block. That's not setting my nose on end either. -- https://mail.python.org/mailman/listinfo/python-list
Re:How to use imported function to get current globals
1989lzhh <1989l...@gmail.com> Wrote in message: > Here is the code > m1.py > def f(): > print globals() > > m2.py > from m1 import f > f()# how to get current module's globals? > As others have said, it's probably a bad idea. I can think of 3 reasons to try: teacher said so, writing a debugger, transliterating code from a crude language into python. Could you elaborate on what you really want? Which of those two modules is your main script? Which code in which module is trying to get which module's globals? And is the connection static or dynamic? And do you want a snapshot of them, or to be able to modify and track changes? -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re:try/except/finally
Frank B Wrote in message: > Ok; this is a bit esoteric. > > So finally is executed regardless of whether an exception occurs, so states > the docs. > > But, I thought, if I from my function first, that should take > precedence. > > au contraire > > Turns out that if you do this: > > try: > failingthing() > except FailException: > return 0 > finally: > return 1 > > Then finally really is executed regardless... even though you told it to > return. > > That seems odd to me. > The thing that's odd to me is that a return is permissible inside a finally block. That return should be at top level, even with the finally line. And of course something else should be in the body of the finally block. If you wanted the finally block to change the return value, it should do it via a variable. retval = 0 try: failingthing() except FailException: return retval finally: retval =1 return something I imagine the finally clause was designed to do cleanup, like closing files. And it certainly predated the with statement. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On Sat, 07 Jun 2014 20:09:37 -0400, Roy Smith wrote: > We've also got machines that are so fast, it's not longer critical that > we squeeze out every last iota of performance. Oh, but wait, now we're > trying to do absurd things like play full-motion video games on phones, > where efficiency equates to battery life. Sigh. That's where there needs to be a concerted push to develop more efficient CPUs and memory, in the engineering sense of efficiency (i.e. better power consumption, not speed). In desktop and server class machines, increasing speed has generated more and more waste heat, to the point where Google likes to build its server farms next to rivers to reduce their air conditioning costs. You can't afford to do that on a battery. Even for desktops and servers, I'd prefer to give up, say, 80% of future speed gains for a 50% reduction in my electricity bill. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: try/except/finally
On Sunday, June 8, 2014 5:17:21 AM UTC+5:30, Chris Angelico wrote: > On Sun, Jun 8, 2014 at 8:49 AM, Ethan Furman wrote: > > I don't remember if I almost had this in real code or if I learned about it > > first, but it can definitely be a gotcha. It seems to me that if the try > > block exits with an explicit return, and then the finally block exits with > > an explicit return, some kind of error ought to be raised. > I'd go a little simpler: A return statement inside a finally block is > code smell. Some people¹ think that gotos are a code-smell. And since both return and exceptions are thinly veiled gotos, what we have here are two smells outsmelling each other. ¹ I am not exactly those people. A chap called E W Dijkstra made the statement: "Goto statement considered harmful" and became famous. The chap who taught me programming said to me: "What the goto does to control structure, the assignment does to data structure" He did not become famous. However in my view he made the more intelligent statement -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.2 has some deadly infection
On 06/05/2014 05:02 PM, Steven D'Aprano wrote: >[...] > But Linux Unicode support is much better than Windows. Unicode support in > Windows is crippled by continued reliance on legacy code pages, and by > the assumption deep inside the Windows APIs that Unicode means "16 bit > characters". See, for example, the amount of space spent on fixing > Windows Unicode handling here: > > http://www.utf8everywhere.org/ While not disagreeing with the the general premise of that page, it has some problems that raise doubts in my mind about taking everything the author says at face value. For example "Q: Why would the Asians give up on UTF-16 encoding, which saves them 50% the memory per character?" [...] in fact UTF-8 is used just as often in those [Asian] countries. That is not my experience, at least for Japan. See my comments in https://mail.python.org/pipermail/python-ideas/2012-June/015429.html where I show that utf8 files are a tiny minority of the text files found by Google. He then gives a table with the size of utf8 and utf16 encoded contents (ie stripped of html stuff) of an unnamed Japanese wikipedia page to show that even without a lot of (html-mandated) ascii, the space savings are not very much compared to the theoretical "50%" savings he stated: " Dense text (Δ UTF-8) UTF-8 ... 222 KB (0%) UTF-16 ... 176 KB (−21%)" Note that he calculates the space saving as (utf8-utf16)/utf8. Yet by that metric the theoretical saving is *NOT* 50%, it is 33%. For example 1000 Japanese characters will use 2000 bytes in utf16 and 3000 in utf8. I did the same test using http://ja.wikipedia.org/wiki/%E7%B9%94%E7%94%B0%E4%BF%A1%E9%95%B7 I stripped html tags, javascript and redundant ascii whitespace characters The stripped utf-8 file was 164946 bytes, the utf-16 encoded version of same was 117756. That gives (using the (utf8-utf16)/utf16 metric he used to claim 50% idealized savings) 40% which is quite a bit closer to the idealized 50% than his 21%. I would have more faith in his opinions about things I don't know about (such as unicode programming on Windows) if his other info were more trustworthy. IOW, just because it's on the internet doesn't mean it's true. -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
Roy Smith : > The original MacOS was written in Pascal (both applications and > kernel). Being able to touch memory locations or registers requires no > more than a few short glue routines written in assembler. Pascal is essentially equivalent to C, except Pascal has a cleaner syntax. I like the fact that the semicolon is a separator. Also, the variable declaration syntax is done more smartly in Pascal. And the pointer/array confusion in C is silly. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: How to use imported function to get current globals
thanks all you guys. I have find the solution which is quite simple by using
sys._frame(1).f_locals in function to get the caller's scope
The following is my user case:
I am writing a tool to translate python code to cython code then compiled using
decorate.
jit, build=make("mymodule")
#jit function collect python code and signature then translate to cython code
@jit('int(int)',
locals='''
int b;
''')
def f(a):
b=1
return a+1
build()# compile cython code and load compiled module then expose compiled
function to current namespace. So this is my purpose to get caller's scope
f()# now f is a compiled function
发自我的 iPhone
> 在 Jun 8, 2014，10:24，Dave Angel 写道：
>
> 1989lzhh <1989l...@gmail.com> Wrote in message:
>> Here is the code
>> m1.py
>> def f():
>>print globals()
>>
>> m2.py
>> from m1 import f
>> f()# how to get current module's globals?
>
> As others have said, it's probably a bad idea. I can think of 3
> reasons to try: teacher said so, writing a debugger,
> transliterating code from a crude language into python.
>
> Could you elaborate on what you really want? Which of those two
> modules is your main script? Which code in which module is trying
> to get which module's globals? And is the connection static or
> dynamic? And do you want a snapshot of them, or to be able to
> modify and track changes?
>
>
>
>
> --
> DaveA
>
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
