Re: Plotting the integer-and-fraction remainder of a function value modulo 360
Kim Plofker writes: > This produces the following error message: Thank you for providing an actual code example (though not one I can run, since it isn't a complete Python program). Particularly, thank you for providing the *actual* error output; this makes it much clearer what is happening. It's always best to show the complete error output since usually there are details in the output that narrow down the problem. > ... > TypeError: unsupported operand type(s) for %: > 'sage.symbolic.expression.Expression' and > 'sage.symbolic.expression.Expression' This is indeed a problem specific to the types defined by Sage. You'll need to start a discussion in a Sage-specific discussion forum. > Many thanks again for any help. You will likely still need assistance with Python to continue with this. Once you have a better idea what part is Sage-specific and what part is general Python, feel free to ask here. Or if you prefer, there is a beginner-level Python discussion forum at https://mail.python.org/mailman/listinfo/tutor>. -- \ “Know what I hate most? Rhetorical questions.” —Henry N. Camp | `\ | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: How to display chinese character in 65001 in pytohn?
On 4/9/2014 11:19 PM, length power wrote: problem solved.if you enter python by python(command line),the problem can't be solved.if you enter python by cmd ,and input |python|,no problem happen. I have also failed trying to use cp65001. I do not understand the solution you claim. Please be more specific with exactly what works. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Plotting the integer-and-fraction remainder of a function value modulo 360
On 4/10/2014 1:03 AM, Kim Plofker wrote:
Thanks, the % operator is indeed what I want, but I want to use it with
a function expression rather than with numbers alone. And that seems to
create a type error.
Here's an example of what goes wrong:
t = var('t')
L(t) = t*725.5%360.0
This produces the following error message:
...
TypeError: unsupported operand type(s) for %:
'sage.symbolic.expression.Expression' and
'sage.symbolic.expression.Expression'
I can use other arithmetic operators such as + and / in this function
expression, but not %, and I don't understand why. Is it indeed a
Sage-specific problem rather than something I could work around in Python?
It seems that someone either forgot to implement % or decided not too.
You will have to ask the sage people.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: threading
On 10/04/2014 00:53, Roy Smith wrote: Natural language is a wonderfully expressive thing. I open the window, stick my head out, look up at the sky, and say, "Raining". Forget the pronoun, I don't even have a verb. And yet everybody understands exactly what I mean. In the UK you can stay in bed and say "Raining" and the odds are you'll be correct :) -- 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: CommandLine Option in Python for filtering values from Column
On 10/04/2014 06:16, balaji marisetti wrote: sys.argv is itself a list. You can directly access the `quality` field as sys.argv[2]. quality = int(sys.argv[2]) However, if you want to use more command line options, then using `argparse` module is better than accessing arguments using `sys.argv`. An alternative is to grab docopt from pypi, it's awesome :) -- 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
xlrd 0.9.3 released!
Hi All, I'm pleased to announce the release of xlrd 0.9.3: http://pypi.python.org/pypi/xlrd/0.9.3 This release includes the following changes: - Github issue #49 - Github issue #64 - skip meaningless chunk of 4 zero bytes between two otherwise-valid BIFF records - Github issue #61 - fix updating of escapement attribute of Font objects read from workbooks. - Implemented Sheet.visibility for xlsx files - Ignore anchors ($) in cell references - Dropped support for Python 2.5 and earlier, Python 2.6 is now the earliest Python release supported - Read xlsx merged cell elements. - Read cell comments in .xlsx files - Added xldate_to_datetime() function to convert from Excel serial date/time to datetime.datetime object. Thanks to the following for their contributions to this release: - John Machin - Caleb Epstein - Martin Panter - John McNamara - Gunnlaugur Þór Briem - Stephen Lewis If you find any problems, please ask about them on the [email protected] list, or submit an issue on GitHub: https://github.com/python-excel/xlrd/issues Full details of all things Python and Excel related can be found here: http://www.python-excel.org/ cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
On Thu, Apr 10, 2014 at 6:23 PM, Mark Lawrence wrote: > On 10/04/2014 00:53, Roy Smith wrote: >> Natural language is a wonderfully expressive thing. I open the window, >> stick my head out, look up at the sky, and say, "Raining". Forget the >> pronoun, I don't even have a verb. And yet everybody understands >> exactly what I mean. >> > > In the UK you can stay in bed and say "Raining" and the odds are you'll be > correct :) Is the staying-in-bed part critical to that? The last few times I've been to England, it's only rained a few times. Granted, I've always come during your summer, but even so, the rumours suggest that rain should still be plenty common. We've happily driven a costume rack down the A53 (twice - once empty, once loaded, if I recall correctly), without worrying about rain. There were a few times when the terrain was treacherous (imagine this: you're at the top of a moderately-steep (probably 1 in 10-20) of rough concrete or asphalt, depending on which part you jog down, and it's been greased up by vehicles standing there, and then rained on; and you need to run down it at full speed, catch the porta-cabin before it closes for the last time this year, get the DVDs that were being run off for you, and run back up at full speed, all before a ceremony begins), but other than that, it's been pretty dry every time we've been there. But we don't stay in bed much. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: CommandLine Option in Python for filtering values from Column
> An alternative is to grab docopt from pypi, it's awesome :) Some time back, I watched a video about that module but, later, I forgot its name. Thanks for reminding me of that module. On 10 April 2014 13:57, Mark Lawrence wrote: > On 10/04/2014 06:16, balaji marisetti wrote: >> >> sys.argv is itself a list. You can directly access the `quality` field >> as sys.argv[2]. >> >> quality = int(sys.argv[2]) >> >> However, if you want to use more command line options, then using >> `argparse` module is better than accessing arguments using `sys.argv`. >> > > An alternative is to grab docopt from pypi, it's awesome :) > > -- > 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 -- :-)balaji -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
"Chris Angelico" wrote in message
news:CAPTjJmq2xx_WG2ymCC0NNqisDO=dnnjhnegpid3de+xeiy5...@mail.gmail.com...
> On Thu, Apr 10, 2014 at 12:30 AM, Frank Millman
> wrote:
>>
>>>
How does one distinguish betwen 'blocking' and 'non-blocking'? Is it
either/or, or is it some arbitrary timeout - if a handler returns
within
that time it is non-blocking, but if it exceeds it it is blocking?
>>>
>>> No; a blocking request is one that waits until it has a response, and
>>> a non-blocking request is one that goes off and does something, and
>>> then comes back to you when it's done.
>>
Thanks for that clarification - I think I've got it now.
>>> def nonblocking_query(id):
>>>print("Finding out who employee #%d is..."%id)
>>>def nextstep(res):
>>>print("Employee #%d is %s."%(id,res[0].name))
>>>db.asyncquery(nextstep, "select name from emp where id=12345")
>>>
>>
>> In this example, what is 'db.asyncquery'?
>>
>> If you mean that you have a separate thread to handle database queries,
>> and
>> you use a queue or other message-passing mechanism to hand it the query
>> and
>> get the result, then I understand it. If not, can you explain in more
>> detail.
>
> It's an imaginary function that would send a request to the database,
> and then call some callback function when the result arrives. If the
> database connection is via a TCP/IP socket, that could be handled by
> writing the query to the socket, and then when data comes back from
> the socket, looking up the callback and calling it. There's no
> additional thread here.
>
I need some time to get my head around that, but meanwhile can you resolve
this stumbling block?
The current version of my program uses HTTP. As I understand it, a client
makes a connection and submits a request. The server processes the request
and returns a result. The connection is then closed.
In this scenario, does async apply at all? There is no open connection to
'select' or 'poll'. You have to ensure that the request handler does not
block the entire process, so that the main loop is ready to accept more
connections. But passing the request to a thread for handling seems an
effective solution.
Am I missing something?
Frank
--
https://mail.python.org/mailman/listinfo/python-list
Re: threading
On Thu, Apr 10, 2014 at 7:17 PM, Frank Millman wrote: > The current version of my program uses HTTP. As I understand it, a client > makes a connection and submits a request. The server processes the request > and returns a result. The connection is then closed. > > In this scenario, does async apply at all? There is no open connection to > 'select' or 'poll'. You have to ensure that the request handler does not > block the entire process, so that the main loop is ready to accept more > connections. But passing the request to a thread for handling seems an > effective solution. Let's take this to a slightly lower level. HTTP is built on top of a TCP/IP socket. The client connects (usually on port 80), and sends a string like this: """GET /foo/bar/asdf.html HTTP/1.0 Host: www.spam.org User-Agent: Mozilla/5.0 """ The server then sends back something like this: """HTTP/1.0 200 OK Content-type: text/html Hello, world! """ These are carried on a straight-forward bidirectional stream socket, so the write and read operations (or send and recv, either way) can potentially block. With a small request, you can kinda assume that the write won't block, but the read most definitely will: it'll block until the server writes something for you. So it follows the usual model of blocking vs non-blocking. In blocking mode, you do something like this: data = socket.read() and it waits until it has something to return. In non-blocking mode, you do something like this: def data_available(socket, data): # whatever socket.set_read_callback(data_available) An HTTP handling library can then build a non-blocking request handler on top of that, by having data_available parse out the appropriate information, and return if it doesn't have enough content yet. So it follows the same model; you send off the request (and don't wait for it), and then get notified when the result is there. When you write the server, you effectively have the same principle, with one additional feature: a listening socket becomes readable whenever someone connects. So you can select() on that socket, just like you can with the others, and whenever there's a new connection, you add it to the collection and listen for requests on all of them. It's basically the same concept; as soon as you can accept a new connection, you do so, and then go back to the main loop. It's pretty simple when you let a lower-level library do the work for you :) The neat thing is, you can put all of this into a single program; I can't demo it in Python for you, but I have a Pike kernel that I wrote for my last job, which can handle a variety of different asynchronous operations: TCP, UDP (which just sends single packets, normally), a GUI (in theory), timers, the lot. It has convenience features for creating a DNS server, an HTTP server, and a stateful line-based server (covers lots of other protocols, like SMTP). And (though this bit would be hard to port to Python) it can update itself without shutting down. Yes, it can take some getting your head around, but it's well worth it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
"Chris Angelico" wrote in message news:CAPTjJmoWaHPZk=DAxbfJ=9ez2aj=4yf2c8wmbryof5vgn6e...@mail.gmail.com... > On Thu, Apr 10, 2014 at 7:17 PM, Frank Millman wrote: >> The current version of my program uses HTTP. As I understand it, a client >> makes a connection and submits a request. The server processes the >> request >> and returns a result. The connection is then closed. >> >> In this scenario, does async apply at all? There is no open connection to >> 'select' or 'poll'. You have to ensure that the request handler does not >> block the entire process, so that the main loop is ready to accept more >> connections. But passing the request to a thread for handling seems an >> effective solution. > [...] Thanks, Chris - I am learning a lot! I have skipped the first part of your reply, as it seems to refer to the client. I am using a web browser as a client, so I don't have to worry about programming that. > > When you write the server, you effectively have the same principle, > with one additional feature: a listening socket becomes readable > whenever someone connects. So you can select() on that socket, just > like you can with the others, and whenever there's a new connection, > you add it to the collection and listen for requests on all of them. > It's basically the same concept; as soon as you can accept a new > connection, you do so, and then go back to the main loop. > This is where it gets interesting. At present I am using cherrypy as a server, and I have not checked its internals. However, in the past I have dabbled with writing server programs like this - while self.running: try: conn,addr = self.s.accept() Session(args=(self, conn)).start() except KeyboardInterrupt: self.shutdown() In this scenario, the loop blocks on 'accept'. You seem to be suggesting that I set the socket to 'non-blocking', use select() to determine when a client is trying to connect, and then call 'accept' on it to create a new connection. If so, I understand your point. The main loop changes from 'blocking' to 'non-blocking', which frees it up to perform all kinds of other tasks as well. It is no longer just a 'web server', but becomes an 'all-purpose server'. Much food for thought! Frank -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
On Thu, Apr 10, 2014 at 9:10 PM, Frank Millman wrote: > You seem to be suggesting that I set the socket to 'non-blocking', use > select() to determine when a client is trying to connect, and then call > 'accept' on it to create a new connection. Right! That's about how it goes. Of course, for production work you'll want to wrap all that up for convenience, but fundamentally, that is what happens. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
"Frank Millman" : > You seem to be suggesting that I set the socket to 'non-blocking', use > select() to determine when a client is trying to connect, and then > call 'accept' on it to create a new connection. Yes. > If so, I understand your point. The main loop changes from 'blocking' > to 'non-blocking', which frees it up to perform all kinds of other > tasks as well. It is no longer just a 'web server', but becomes an > 'all-purpose server'. The server will do whatever you make it do. Other points: * When you wake up from select() (or poll(), epoll()), you should treat it as a hint. The I/O call (accept()) could still raise socket.error(EAGAIN). * The connections returned from accept() have to be individually registered with select() (poll(), epoll()). * When you write() into a connection, you may be able to send only part of the data or get EAGAIN. You need to choose a buffering strategy -- you should not block until all data is written out. Also take into account how much you are prepared to buffer. * There are two main modes of multiplexing: level-triggered and edge-triggered. Only epoll() (and kqueue()) support edge-triggered wakeups. Edge-triggered requires more discipline from the programmer but frees you from having to tell the multiplexing facility if you are interested in readability or writability in any given situation. Edge-triggered wakeups are only guaranteed after you have gotten an EAGAIN from an operation. Make sure you keep on reading/writing until you get an EAGAIN. On the other hand, watch out so one connection doesn't hog the process because it always has active I/O to perform. * You should always be ready to read to prevent deadlocks. * Sockets can be half-closed. Your state machines should deal with the different combinations gracefully. For example, you might read an EOF from the client socket before you have pushed the response out. You must not close the socket before the response has finished writing. On the other hand, you should not treat the half-closed socket as readable. * While a single-threaded process will not have proper race conditions, you must watch out for preemption. IOW, you might have Object A call a method of Object B, which calls some other method of Object A. Asyncio has a task queue facility. If you write your own main loop, you should also implement a similar task queue. The queue can then be used to make such tricky function calls in a safe context. * Asyncio provides timers. If you write your own main loop, you should also implement your own timers. Note that modern software has to tolerate suspension (laptop lid, virtual machines). Time is a tricky concept when your server wakes up from a coma. * Specify explicit states. Your connection objects should have a data member named "state" (or similar). Make your state transitions explicit and obvious in the code. In fact, log them. Resist the temptation of deriving the state implicitly from other object information. * Most states should be guarded with a timer. Make sure to document for each state, which timers are running. * In each state, check that you handle all possible events and timeouts. The state/transition matrix will be quite sizable even for seemingly simple tasks. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and Unicode
Le mercredi 9 avril 2014 10:53:36 UTC+2, Mark Lawrence a écrit : > On 09/04/2014 09:07, [email protected] wrote: > > > Well, there is a (serious) problem somewhere... > > > > > > jmf > > > > > > > Look in a mirror and you'll see it as it'll be staring you in the face. > > > > -- > > My fellow Pythonistas, ask not what our language can do for you, ask > > what you can do for our language. > > > > Mark Lawrence > > > -- https://mail.python.org/mailman/listinfo/python-list
Language summit notes
Today in Montreal Canada, there was a Language Summit to discuss the future of Python. Some highlights: PyPy is only three bug fixes away from shipping support for Python 3.2! Guido confirms that easing the transition from 2.x to 3.x code is a major priority. Version 2.7 is alive and in good health and not ready to be retired yet, but he's still against releasing a version 2.8. Both IronPython and Jython hope to support Python 3 soon, Jython is being held back by a lack of contributors. Packaging is hard. Very hard. There is a lot of work going on to try to improve packaging. After five years experience in managing the transition between 2 and 3, the official recommendation is now the opposite of what it was five years ago: write a single code-base aimed at both 2 and 3, rather than trying to automate translation via 2to3 or other tools. There is a lot of interest for optional type checking. More in this email thread here: https://mail.python.org/pipermail/python-dev/2014-April/133873.html -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and Unicode
On 2014-04-10 04:47, [email protected] wrote: > Le mercredi 9 avril 2014 10:53:36 UTC+2, Mark Lawrence a écrit : > > On 09/04/2014 09:07, [email protected] wrote: > > > > > Well, there is a (serious) problem somewhere... > > > jmf > > > > Look in a mirror and you'll see it as it'll be staring you in the > > face. Hmm...both members of the conversation posted provocative & inflammatory statements, but one provided a way to reproduce an problem... Is either issue one that the Python community cares about? Until the problem can be reproduced *and the solution doesn't cause more problems than the existing condition*, the answer is likely "no." -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
In article <[email protected]>, Marko Rauhamaa wrote: > * When you wake up from select() (or poll(), epoll()), you should treat >it as a hint. The I/O call (accept()) could still raise >socket.error(EAGAIN). People often misunderstand what select() does. The common misconception is that a select()ed descriptor has data waiting to be read. What the man page says is, "A file descriptor is considered ready if it is possible to perform the corresponding I/O operation (e.g., read(2)) without blocking." Not blocking includes failing immediately. And, once you introduce threading, things get even more complicated. Imagine two threads, both waiting in a select() call on the same socket. Data comes in on that socket. Both select() calls return. If both threads then do reads on the socket, you've got a race condition. One of them will read the data. The other will block in the read call, because the data has already been read by the other thread! So, yes, as Marko says, use select() as a hint, but then also do your reads in non-blocking mode, and be prepared for them to fail, regardless of whether select() said the descriptor was ready. >Note that modern software has to tolerate suspension (laptop lid, >virtual machines). Time is a tricky concept when your server wakes up >from a coma. Not to mention running in a virtual machine. Time is an equally tricky concept when your hardware clock is really some other piece of software playing smoke and mirrors. I once worked on a time-sensitive system which was running in a VM. The idiots who had configured the thing were running ntpd in the VM, to keep its clock in sync. Normally, this is a good thing, but they were ALSO using the hypervisor's clock management gizmo (vmtools?) to adjust the VM clock. The two mechanisms were fighting with each other, which did really weird stuff to time. It took me forever to figure out what was going on. How does one even observe that time is moving around randomly? I eventually ended up writing a trivial NTP client in Python (it's only a few lines of code) and periodically logging the difference between the local system clock and what my NTP reference was telling me. Of course, figuring out what was going on was the easy part. Convincing the IT drones to fix the problem was considerably more difficult. > * In each state, check that you handle all possible events and >timeouts. The state/transition matrix will be quite sizable even for >seemingly simple tasks. And, those empty boxes in the state transition matrix which are blank, because those transitions are impossible? Guess what, they happen, and you better have a plan for when they do :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
On 4/9/14 12:52 PM, Chris Angelico wrote: People with a fear of threaded programming almost certainly never grew up on OS/2. :) I learned about GUI programming thus: Write your synchronous message handler to guarantee that it will return in an absolute maximum of 0.1s, preferably a lot less. If you have any sort of heavy processing to do, spin off a thread. heh very true. Any non trivial OS/2 GUI app required threads. We had a template at our shop that we gave to noobs for copy-n-tweak. It had not only the basics for getting the canvas on the screen with a tool bar and a button, but also the minimal code required to setup the thread to handle the button event (it was a database lookup in our case). -- https://mail.python.org/mailman/listinfo/python-list
why i have the output of [None, None, None]
>>> x=['','x1','x2','x3',' ']
>>> x
['', 'x1', 'x2', 'x3', ' ']
>>> [print("ok") for it in x if it.strip() !=""]
ok
ok
ok
[None, None, None]
i understand there are three 'ok' in the output,but why i have the output
of [None, None, None]
--
https://mail.python.org/mailman/listinfo/python-list
Re: why i have the output of [None, None, None]
The print function in Python 3 returns None. The "ok" output is a side
effect. The actual value of evaluating that list comprehension is a
list of three None values.
Skip
On Thu, Apr 10, 2014 at 8:54 AM, length power wrote:
x=['','x1','x2','x3',' ']
x
> ['', 'x1', 'x2', 'x3', ' ']
[print("ok") for it in x if it.strip() !=""]
> ok
> ok
> ok
> [None, None, None]
>
> i understand there are three 'ok' in the output,but why i have the output of
> [None, None, None]
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: how to make ["a","b",["c","d"],"e"] into ['a', 'b', 'c', 'd', 'e'] ?
Rustom Mody wrote: def fl1(l): return [y for x in l for y in x] # recursive flatten def fr(l): ... if not isinstance(l,list): return [l] ... return fl1([fr(x) for x in l]) For a short non-recursive procedure - not a function, modifies L in-place but none of its sublists. >>> def flatten(L) : for k,_ in enumerate(L) : while isinstance(L[k],list) : L[k:k+1]=L[k] flattens L to any depth, eg >>> L=[1,[2,[3,4]],5,6,[[7],8]] >>> flatten(L) >>> L [1, 2, 3, 4, 5, 6, 7, 8] --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: why i have the output of [None, None, None]
This is called imperative programming:
for it in x:
... if it.strip() != '':
...print ("Ok")
This is called functional programming:
>>> [y for y in x if y.strip() != '']
['x1', 'x2', 'x3']
What you have is a confusion:
print is imperative
comprehension is functional
You should not mix them like that
--
https://mail.python.org/mailman/listinfo/python-list
Re: why i have the output of [None, None, None]
length power writes:
> >>> x=['','x1','x2','x3',' ']
> >>> x
> ['', 'x1', 'x2', 'x3', ' ']
> >>> [print("ok") for it in x if it.strip() !=""]
> ok
> ok
> ok
> [None, None, None]
>
> i understand there are three 'ok' in the output,but why i have the
> output of [None, None, None]
It's a list containing the values from three invocations of print.
You get it because you asked for it.
|>>> print("ok") == None
|ok
|True
|>>> print("ok") != None
|ok
|False
|>>> [(print("ok") or "die") for x in (1,2,3)]
|ok
|ok
|ok
|['die', 'die', 'die']
|>>> [print("ok") for x in (1,2,3)] and print("What do you want it to be?")
|ok
|ok
|ok
|What do you want it to be?
|>>>
(That last one actually returns None to the interpreter, which
promptly does not print it.)
--
https://mail.python.org/mailman/listinfo/python-list
Re: why i have the output of [None, None, None]
because thats the return value of [...]
print retuns None.
On 10.04.2014 15:54, length power wrote:
>>> x=['','x1','x2','x3',' ']
>>> x
['', 'x1', 'x2', 'x3', ' ']
>>> [print("ok") for it in x if it.strip() !=""]
ok
ok
ok
[None, None, None]
i understand there are three 'ok' in the output,but why i have the
output of [None, None, None]
--
Johannes Schneider
Webentwicklung
[email protected]
Tel.: +49.228.42150.xxx
Galileo Press GmbH
Rheinwerkallee 4 - 53227 Bonn - Germany
Tel.: +49.228.42.150.0 (Zentrale) .77 (Fax)
http://www.galileo-press.de/
Geschäftsführer: Tomas Wehren, Ralf Kaulisch, Rainer Kaltenecker
HRB 8363 Amtsgericht Bonn
--
https://mail.python.org/mailman/listinfo/python-list
Re: how to make ["a","b",["c","d"],"e"] into ['a', 'b', 'c', 'd', 'e'] ?
Boris Borcic wrote: Rustom Mody wrote: def fl1(l): return [y for x in l for y in x] # recursive flatten def fr(l): ... if not isinstance(l,list): return [l] ... return fl1([fr(x) for x in l]) For a short non-recursive procedure - not a function, modifies L in-place but none of its sublists. >>> def flatten(L) : for k,_ in enumerate(L) : while isinstance(L[k],list) : L[k:k+1]=L[k] flattens L to any depth, eg >>> L=[1,[2,[3,4]],5,6,[[7],8]] >>> flatten(L) >>> L [1, 2, 3, 4, 5, 6, 7, 8] Mh, this will fail though if the last item (of the last item (of the...)) is an empty list, eg L=[[]]. If you want to cover this case you can wrap the inside of the proc with a try except IndexError: pass, in which case you can also simplify the enumerate(L) to an indefinite counter. Or insert a dummy value before starting and pop it off at the end. --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
Marko Rauhamaa wrote: > Other points: > > * When you wake up from select() (or poll(), epoll()), you should treat >it as a hint. The I/O call (accept()) could still raise >socket.error(EAGAIN). > > * The connections returned from accept() have to be individually >registered with select() (poll(), epoll()). > > * When you write() into a connection, you may be able to send only part >of the data or get EAGAIN. You need to choose a buffering strategy -- >you should not block until all data is written out. Also take into >account how much you are prepared to buffer. > > * There are two main modes of multiplexing: level-triggered and >edge-triggered. Only epoll() (and kqueue()) support edge-triggered >wakeups. Edge-triggered requires more discipline from the programmer >but frees you from having to tell the multiplexing facility if you >are interested in readability or writability in any given situation. > >Edge-triggered wakeups are only guaranteed after you have gotten an >EAGAIN from an operation. Make sure you keep on reading/writing until >you get an EAGAIN. On the other hand, watch out so one connection >doesn't hog the process because it always has active I/O to perform. > > * You should always be ready to read to prevent deadlocks. > > * Sockets can be half-closed. Your state machines should deal with the >different combinations gracefully. For example, you might read an EOF >from the client socket before you have pushed the response out. You >must not close the socket before the response has finished writing. >On the other hand, you should not treat the half-closed socket as >readable. > > * While a single-threaded process will not have proper race conditions, >you must watch out for preemption. IOW, you might have Object A call >a method of Object B, which calls some other method of Object A. >Asyncio has a task queue facility. If you write your own main loop, >you should also implement a similar task queue. The queue can then be >used to make such tricky function calls in a safe context. > > * Asyncio provides timers. If you write your own main loop, you should >also implement your own timers. > >Note that modern software has to tolerate suspension (laptop lid, >virtual machines). Time is a tricky concept when your server wakes up >from a coma. > > * Specify explicit states. Your connection objects should have a data >member named "state" (or similar). Make your state transitions >explicit and obvious in the code. In fact, log them. Resist the >temptation of deriving the state implicitly from other object >information. > > * Most states should be guarded with a timer. Make sure to document for >each state, which timers are running. > > * In each state, check that you handle all possible events and >timeouts. The state/transition matrix will be quite sizable even for >seemingly simple tasks. And exactly how is getting all of this correct any easier than just using threads and blocking i/o? I'd like to see the programmer who can get all of this correct, but has no idea how to use a queue og mutex without deadlocking. Sturla -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
On Fri, Apr 11, 2014 at 1:24 AM, Sturla Molden wrote: > And exactly how is getting all of this correct any easier than just using > threads and blocking i/o? For a start, nearly everything Marko just posted should be dealt with by your library. I don't know Python's asyncio as it's very new and I haven't yet found an excuse to use it, but with Pike, I just engage backend mode, set callbacks on the appropriate socket/file/port objects, and let things happen perfectly. All I need to do is check a few return values (eg if I ask a non-blocking socket to write a whole pile of data, it might return that it wrote only some of it, in which case I have to buffer the rest - not hard but has to be done), and make sure I always return promptly from my callbacks so as to avoid lagging out other operations. None of the details of C-level APIs matter to my high level code. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Teaching python to non-programmers
Dear List Recently I was requested to teach python to a group of students of GIS (Geographic Information Systems). Their knowledge of programming is zero. The objective is to enable them to write plug-ins for GIS software like QGIS and ArcGIS. It would require them to learn, besides core python, PyQt, QtDesigner. So my plan is to teach them core python, PyQt, Qt Designer, in that order. A kind of "bottom up approach". But the students seem to feel that I should use "top down approach". That is, show them how to write a plug-in, then PyQt and Qt Designer and then enough of python so they can handle the above. I don't think, that is possible or a good idea. But I would like to know, if there are any other approaches. Thanks and Regards Lalitha Prasad, -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
Sturla Molden : > And exactly how is getting all of this correct any easier than just > using threads and blocking i/o? > > I'd like to see the programmer who can get all of this correct, but > has no idea how to use a queue og mutex without deadlocking. My personal experience is that it is easier to get "all of this correct" than threads. I've done it both ways. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
Chris Angelico : > For a start, nearly everything Marko just posted should be dealt with > by your library. Let's not kid ourselves: it is hard to get any reactive system right. > I don't know Python's asyncio as it's very new and I haven't yet found > an excuse to use it, but with Pike, I just engage backend mode, set > callbacks on the appropriate socket/file/port objects, and let things > happen perfectly. That "set callbacks" and "let things happen" is the hard part. The framework part is trivial. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
On Fri, Apr 11, 2014 at 2:25 AM, Marko Rauhamaa wrote:
>> I don't know Python's asyncio as it's very new and I haven't yet found
>> an excuse to use it, but with Pike, I just engage backend mode, set
>> callbacks on the appropriate socket/file/port objects, and let things
>> happen perfectly.
>
> That "set callbacks" and "let things happen" is the hard part. The
> framework part is trivial.
Maybe. Here's a simple self-contained Pike program that makes a simple
echo server - whatever comes in goes out again:
//Create the port (listening connection).
object mainsock=Stdio.Port(12345,accept_callback);
void accept_callback()
{
//Get the newly-connected socket
object sock=mainsock->accept();
//Set up its callbacks
sock->set_nonblocking(read_callback, write_callback, close_callback);
//Keep track of metadata (here that'll just be the write buffer)
sock->set_id((["sock":sock]));
}
//Attempt to write some text, buffering any that can't be written
void write(mapping info, string text)
{
if (!text || text=="") return;
if (info->write_me)
{
//There's already buffered text. Queue this text too.
info->write_me += text;
return;
}
int written = info->sock->write(text);
if (written < 0)
{
//Deal with write errors brutally by closing the socket.
info->sock->close();
return;
}
info->write_me = text[written..];
}
//When more can be written, write it.
void write_callback(mapping info) {write(info, m_delete(info,"write_me"));}
void read_callback(mapping info, string data)
{
//Simple handling: Echo the text back with a prefix.
//Note that this isn't line-buffered or anything.
write(info, ">> " + data);
}
//Not strictly necessary, but if you need to do something when a client
//disconnects, this is where you'd do it.
void close_callback(mapping info)
{
info->sock = "(disconnected)";
}
//Engage backend mode.
int main() {return -1;}
Setting callbacks? One line. There's a little complexity to the "write
what you can, buffer the rest", but if you're doing anything even a
little bit serious, you'll just bury that away in a mid-level library
function. The interesting part is in the read callback, which does the
actual work (in this case, it just writes back whatever it gets). And
here's how easy it is to make it into a chat server: just replace the
read and close callbacks with these:
multiset(mapping) sockets=(<>);
void read_callback(mapping info, string data)
{
//Simple handling: Echo the text back with a prefix.
//Note that this isn't line-buffered or anything.
sockets[info] = 1;
write(indices(sockets)[*], ">> " + data);
}
//Not strictly necessary, but if you need to do something when a client
//disconnects, this is where you'd do it.
void close_callback(mapping info)
{
info->sock = "(disconnected)";
sockets[info] = 0;
}
If you want to handle more information (maybe get users to log in?),
you just stuff more stuff into the info mapping (it's just like a
Python dict). Handling of TELNET negotiation, line buffering, etc,
etc, can all be added between this and the user-level code - that's
what I did with the framework I wrote for work. Effectively, you just
write one function (I had it double as the read and close callbacks
for simplicity), put a declaration down the bottom to say what port
number you want (hard coded to 12345 in the above code), and
everything just happens. It really isn't hard to get callback-based
code to work nicely if you think about what you're doing.
I expect it'll be similarly simple with asyncio; does someone who's
worked with it feel like implementing similar functionality?
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: how to make ["a","b",["c","d"],"e"] into ['a', 'b', 'c', 'd', 'e'] ?
I've been using compiler.ast.flatten, but I have comments indicating it will need be replaced if/when I move to Python 3. I don't pollute my code base with flatten, I just call my own version in my utility library that is currently redirecting to flatten. flatten works equally well with tuples as lists and I'm going to remain consistent with that. My version returns a tuple as well. My love affair with the immutable, hashable, and wonderfully named tuple is perhaps something that needs its own thread, or private room. On Wednesday, April 9, 2014 10:14:49 PM UTC-7, length power wrote: > >>> x=["a","b",["c","d"],"e"] > >>> y=x[2] > >>> y > ['c', 'd'] > >>> x.insert(2,y[0]) > >>> x > > ['a', 'b', 'c', ['c', 'd'], 'e'] > >>> x.insert(3,y[1]) > >>> x > ['a', 'b', 'c', 'd', ['c', 'd'], 'e'] > > >>> del x[4] > >>> x > ['a', 'b', 'c', 'd', 'e'] > >>> > maybe there is a more smart way to do. -- https://mail.python.org/mailman/listinfo/python-list
Re: Teaching python to non-programmers
Don't underestimate the value of morale. Python is a scripting language. You don't need to teach them very much python to get something working, and you can always revisit the initial code and refactor it for better coding hygiene. Someday they might have jobs, and be required to learn things in more of a top down order. ;) On Thursday, April 10, 2014 8:54:48 AM UTC-7, Lalitha Prasad K wrote: > Dear List > > Recently I was requested to teach python to a group of students of GIS > (Geographic Information Systems). Their knowledge of programming is zero. The > objective is to enable them to write plug-ins for GIS software like QGIS and > ArcGIS. It would require them to learn, besides core python, PyQt, > QtDesigner. So my plan is to teach them core python, PyQt, Qt Designer, in > that order. A kind of "bottom up approach". But the students seem to feel > that I should use "top down approach". That is, show them how to write a > plug-in, then PyQt and Qt Designer and then enough of python so they can > handle the above. I don't think, that is possible or a good idea. But I would > like to know, if there are any other approaches. > > > > Thanks and Regards > > > > > > > Lalitha Prasad, -- https://mail.python.org/mailman/listinfo/python-list
Re: why i have the output of [None, None, None]
On 4/10/2014 9:54 AM, length power wrote:
>>> x=['','x1','x2','x3',' ']
>>> x
['', 'x1', 'x2', 'x3', ' ']
>>> [print("ok") for it in x if it.strip() !=""]
Don't use comprehensions for side effects. To get what you want, just
write normal code.
for it in x:
if it.strip() != '':
print('ok')
ok
ok
ok
[None, None, None]
i understand there are three 'ok' in the output,but why i have the
output of [None, None, None]
Reread the ref manual section on comprehensions.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: threading
On Thursday, April 10, 2014 10:38:49 PM UTC+5:30, Chris Angelico wrote: > On Fri, Apr 11, 2014 at 2:25 AM, Marko Rauhamaa wrote: > >> I don't know Python's asyncio as it's very new and I haven't yet found > >> an excuse to use it, but with Pike, I just engage backend mode, set > >> callbacks on the appropriate socket/file/port objects, and let things > >> happen perfectly. > > > > That "set callbacks" and "let things happen" is the hard part. The > > framework part is trivial. > > Maybe. Here's a simple self-contained Pike program that makes a simple > echo server - whatever comes in goes out again: > For analogy let me take a 'thought-discussion' between a C programmer and a python programmer regarding data structures. - PP: Is it not tedious and error prone, C's use of data structures? How/Why do you stick to that? CP: Oh! Is it? And what do you propose I use? PP: Why python of course! Or any modern language with first class data and garbage collection! Why spend a lifetime tracking malloc errors?! CP: Oh! is it? And what is python implemented in? PP: But thats the whole point! Once Guido-n-gang have done their thing we are unscathed by the bugs that prick and poke and torment you day in day out. CP: Lets look at this in more detail shall we? PP: Very well CP: You give me any python data structure (so-called) and I'll give it to you in C. And note: Its very easy. I just open up the python implementation (its in C in case you forgot) and clean up all the mess that has been added for the support of lazy python programmers. In addition, I'll give you a couple of more data-structures/algorithms that we have easy access to but for you, your only choice is to drop into C to use (HeHe!) PP: You are setting the rules of the game... and winning. I did not say I want fancy algorithms and data structures. I said I want (primarily) the safety of garbage collection. Its also neat to have an explicit syntax for basic data types like lists rather than scrummaging around with struct and malloc and pointers (hoo boy!) CP: Yeah.. Like I said you like to be mollycoddled; we like our power and freedom --- If I may use somewhat heavy brush-strokes: Marco (and evidently Chris) are in the CP camp whereas Sturla is in the PP camp. Its just the 'data-structures (and algorithms)' is now replaced by 'concurrency' Both these viewpoints assume that the status quo of current (mainstream) language support for concurrency is a given and not negotiable. Erlang/Go etc disprove this. -- https://mail.python.org/mailman/listinfo/python-list
so module loading fails
Hi, I am trying to get PyQt5 to work. I already posted on their list but with no luck and since the question is rather general I am reposting it here: I built my own module "Entity.so". Trying to import it yields the following error: Python 3.4.0 (default, Apr 8 2014, 22:02:32) [GCC 4.6.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import Entity Traceback (most recent call last): File "", line 1, in ImportError: dynamic module does not define init function (PyInit_Entity) >>> Checking the symbols of Entity.so gives: # nm Entity.so | grep PyInit_Entity 1e5c t PyInit_Entity 00206850 b _ZZ13PyInit_EntityE11sip_methods 002062c0 d _ZZ13PyInit_EntityE14sip_module_def Thus, the symbols exist. Why doesn't python find them? How can I find out more about where locating the symbols fails? Best, Eddy -- https://mail.python.org/mailman/listinfo/python-list
Re: Teaching python to non-programmers
On Thursday, April 10, 2014 9:24:48 PM UTC+5:30, Lalitha Prasad K wrote: > Dear List > > Recently I was requested to teach python to a group of students of GIS > (Geographic Information Systems). Their knowledge of programming is zero. The > objective is to enable them to write plug-ins for GIS software like QGIS and > ArcGIS. It would require them to learn, besides core python, PyQt, > QtDesigner. So my plan is to teach them core python, PyQt, Qt Designer, in > that order. A kind of "bottom up approach". But the students seem to feel > that I should use "top down approach". That is, show them how to write a > plug-in, then PyQt and Qt Designer and then enough of python so they can > handle the above. I don't think, that is possible or a good idea. But I would > like to know, if there are any other approaches. > > > Thanks and Regards Theres a Mulla Nassr Eddin story: Villagers A and B had a dispute. They went to Mulla. A gave his harangue for a while... Mulla: You are right! The B came and gave his story Mulla (to B) You are right Mulla's wife (scratching her head): But Mulla?! Both cant be right?!?! Mulla: You are right. When you are a teacher you have to learn to say "Yes Yes!" to all sorts of demands -- from curriculum, boards, colleagues, and of course students And then keep on doing what you know is right! I have some writings on the stupidities of CS edu establishment http://blog.languager.org/2011/02/cs-education-is-fat-and-weak-1.html and following -- https://mail.python.org/mailman/listinfo/python-list
Re: Teaching python to non-programmers
On 10/04/2014 18:53, [email protected] wrote: Don't underestimate the value of morale. Python is a scripting language. You don't need to teach them very much python to get something working, and you can always revisit the initial code and refactor it for better coding hygiene. Someday they might have jobs, and be required to learn things in more of a top down order. ;) On Thursday, April 10, 2014 8:54:48 AM UTC-7, Lalitha Prasad K wrote: Dear List Recently I was requested to teach python to a group of students of GIS (Geographic Information Systems). Their knowledge of programming is zero. The objective is to enable them to write plug-ins for GIS software like QGIS and ArcGIS. It would require them to learn, besides core python, PyQt, QtDesigner. So my plan is to teach them core python, PyQt, Qt Designer, in that order. A kind of "bottom up approach". But the students seem to feel that I should use "top down approach". That is, show them how to write a plug-in, then PyQt and Qt Designer and then enough of python so they can handle the above. I don't think, that is possible or a good idea. But I would like to know, if there are any other approaches. Thanks and Regards Lalitha Prasad, Just awesome, not only do we have double line spacing and single line paragraphs, we've also got top posting, oh boy am I a happy bunny :) I'll leave someone3 else to explain, I just can't be bothered. -- 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: Method(s) called by square brackets, slice objects
Thanks to both Ethan and Steven for their replies. Steven: I was trying to use the interpreter and wasn't getting results that I understood -- because I didn't know that __getslice__ was simply gone in Python 3. I implemented a __getslice__ method in my subclass that never got called. Ethan: I saw that slice objects were being sent to __getitem__, but that confused me as I thought that its purpose, as implied by the method name, was to return a SINGLE item. OK, I think that I've got all that sorted out! -- https://mail.python.org/mailman/listinfo/python-list
Sorted Containers
I've just chanced upon this and thought it might be of interest to some of you, haven't tried it myself http://www.grantjenks.com/docs/sortedcontainers/ -- 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: threading
Rustom Mody : > Marco (and evidently Chris) are in the CP camp whereas Sturla is in > the PP camp. Its just the 'data-structures (and algorithms)' is now > replaced by 'concurrency' > > Both these viewpoints assume that the status quo of current > (mainstream) language support for concurrency is a given and not > negotiable. I think you misread me (us?). I'm not trying to make life hard on myself. Nor am I disparaging fitting abstractions and high-level utilities. Threads are an essential tool when used appropriately. However, I do believe the 90's fad of treating them like a silver bullet of concurrency was a big mistake. The industry is noticing it, as is evident in NIO and asyncio. Threads are enticing in that they make it quick to put together working prototypes. The difficulties only appear when it's too late to go back. They definitely are not the high-level abstraction you're looking for. > Erlang/Go etc disprove this. http://en.wikipedia.org/wiki/Leonhard_Euler# Personal_philosophy_and_religious_beliefs>: n a + b Sir, -- = x, hence God exists—reply! n Seriously, Erlang (and Go) have nice tools for managing state machines and concurrency. However, Python (and C) are perfectly suitable for clear asynchronous programming idioms. I'm happy that asyncio is happening after all these long years. It would be nice if it supported edge-triggered wakeups, but I suppose that isn't supported in all operating systems. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: imaplib: how to specify SSL/TLS protocol version?
Grant Edwards invalid.invalid> writes: > > Experiments show that when calling ssl.wrap_socket() I have to specify > ssl_version=PROTOCOL_TLSv1 to avoid the above error. > > How do I tell imaplib to use TLS1 instead of SSL3? Use Python 3 and pass the ssl_context parameter to IMAP_SSL: https://docs.python.org/3.3/library/imaplib.html#imaplib.IMAP4_SSL Regards Antoine. -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
On Friday, April 11, 2014 1:14:01 AM UTC+5:30, Marko Rauhamaa wrote:
>
>
> Seriously, Erlang (and Go) have nice tools for managing state machines
> and concurrency. However, Python (and C) are perfectly suitable for
> clear asynchronous programming idioms. I'm happy that asyncio is
> happening after all these long years. It would be nice if it supported
> edge-triggered wakeups, but I suppose that isn't supported in all
> operating systems.
>
Yes... Let me restate what (I hear you as) saying
Lets start with pure uniprocessor machines for ease of discussion (also of
history)
An OS, sits between the uni-hardware and provides
multi{processing,users,threads,etc}.
How does it do it? By the mechanisms process-switching, interleaving etc
In short all the good-stuff... that constitutes asyncio (and relations)
What you are saying is that what the OS is doing, you can do better.
Analogous to said C programmer saying that what (data structures) the python
programmer can make he can do better.
Note I dont exactly agree with Sturla either.
To see that time-shift the C/Python argument 30 years back when it was
imperative
languages vs poorly implemented, buggy, interpreted Lisp/Prolog.
In that world, your 'I'd rather do it by hand/work out my state machine'
would make considerable sense.
Analogously, if the only choice were mainstream (concurrency-wise) languages --
C/C++/Java/Python -- + native threads + overheads + ensuing errors/headaches,
then
the: "Please let me work out my state machine and manage my affairs" would be
sound.
But its not the only choice!!
> http://en.wikipedia.org/wiki/Leonhard_Euler#Personal_philosophy_and_religious_beliefs
>
> n
> a + b
> Sir, -- = x, hence God exists--reply!
>n
I always thought that God exists because was e^(ipi) + 1 = 0 :D
Evidently (s)he has better reasons for existing!
--
https://mail.python.org/mailman/listinfo/python-list
ANN: eGenix pyOpenSSL Distribution 0.13.3.1.0.1.7
ANNOUNCING
eGenix.com pyOpenSSL Distribution
Version 0.13.3.1.0.1.7
An easy-to-install and easy-to-use distribution
of the pyOpenSSL Python interface for OpenSSL -
available for Windows, Mac OS X and Unix platforms
This announcement is also available on our web-site for online reading:
http://www.egenix.com/company/news/eGenix-pyOpenSSL-Distribution-0.13.3.1.0.1.7.html
INTRODUCTION
The eGenix.com pyOpenSSL Distribution includes everything you need to
get started with SSL in Python.
It comes with an easy-to-use installer that includes the most recent
OpenSSL library versions in pre-compiled form, making your application
independent of OS provided OpenSSL libraries:
http://www.egenix.com/products/python/pyOpenSSL/
pyOpenSSL is an open-source Python add-on that allows writing SSL/TLS-
aware network applications as well as certificate management tools:
https://launchpad.net/pyopenssl/
OpenSSL is an open-source implementation of the SSL/TLS protocol:
http://www.openssl.org/
NEWS
This new release of the eGenix.com pyOpenSSL Distribution updates only
the included OpenSSL version to address a serious bug in
OpenSSL 1.0.1 versions:
New in OpenSSL
--
* Updated included OpenSSL libraries from OpenSSL 1.0.1e to
1.0.1f. See http://www.openssl.org/news/news.html and
http://www.openssl.org/news/vulnerabilities.html for a complete
list of changes, most important:
- CVE-2014-0160 ("Heartbleed Bug"): A missing bounds check in the
handling of the TLS heartbeat extension can be used to reveal
up to 64kB of memory to a connected client or server. This issue
did not affect versions of OpenSSL prior to 1.0.1. For information,
also have a look at the Heartbeet Bug website:
http://heartbleed.com/
As always, we provide binaries that include both pyOpenSSL and the
necessary OpenSSL libraries for all supported platforms:
Windows x86 and x64, Linux x86 and x64, Mac OS X PPC, x86 and x64.
We've also added egg-file distribution versions of our eGenix.com
pyOpenSSL Distribution for Windows, Linux and Mac OS X to the
available download options. These make setups using e.g. zc.buildout
and other egg-file based installers a lot easier.
DOWNLOADS
The download archives and instructions for installing the package can
be found at:
http://www.egenix.com/products/python/pyOpenSSL/
UPGRADING
Before installing this version of pyOpenSSL, please make sure that
you uninstall any previously installed pyOpenSSL version. Otherwise,
you could end up not using the included OpenSSL libs.
___
SUPPORT
Commercial support for these packages is available from eGenix.com.
Please see
http://www.egenix.com/services/support/
for details about our support offerings.
MORE INFORMATION
For more information about the eGenix pyOpenSSL Distribution, licensing
and download instructions, please visit our web-site or write to
[email protected].
Enjoy,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
--
https://mail.python.org/mailman/listinfo/python-list
Re: threading
Rustom Mody : > What you are saying is that what the OS is doing, you can do better. > Analogous to said C programmer saying that what (data structures) the > python programmer can make he can do better. I'm sorry, but I don't quite follow you there. I see the regular multithreaded approach as (1) oversimplification which makes it difficult to extend the design and handle all of the real-world contingencies (2) inviting race conditions carelessly--no mortal is immune. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Teaching python to non-programmers
> > Just awesome, not only do we have double line spacing and single line > > paragraphs, we've also got top posting, oh boy am I a happy bunny :) > > I'll leave someone3 else to explain, I just can't be bothered. > > Do you get paid to be a jerk, or is it just for yuks? If the latter, you're not funny. -- https://mail.python.org/mailman/listinfo/python-list
Re: Yet Another Switch-Case Syntax Proposal
On 6 April 2014 20:07, Chris Angelico rosuav-at-gmail.com |[email protected]| wrote: > Here's a simpler form of the proposal, which might cover what you > need. It's basically a short-hand if/elif tree. > > case expression comp_op expression: > suite > case [comp_op] expression: > suite > > else: > suite I like this solution, but I tought about a simpler one. Basically it's my first proposal with two modifications: 1. case / elcase instead of continue, as before 2. if the case expression is a *tuple* (and not any one iterable), case suite is executed if the switched expression is an element of the tuple. If you want to match exactly a tuple, you have simply to put it into another tuple of length 1. Tricky but too much rare to care about. To recap: switch_stmt ::= "switch" expression "case" expression_list ":" suite ("case" | "elcase" expression_list ":" suite)* ["else" ":" suite] 1. if expression_list is a tuple, the case suite will be executed if the switch expression is a member of the tuple. 2. if expression_list is not a tuple, the case suite will be executed if the switch expression is equal Example: briefing_days = ("Tue", "Thu") normal_days = ("Mon", "Wed", "Fri") switch day normal_days + briefing_days: go_to_work = True day_type = "weekday" case normal_days: lunch_time = datetime.time(12) meeting_time = datetime.time(14) elcase briefing_days: lunch_time = datetime.time(11, 30) meeting_time = datetime.time(12, 30) else: go_to_work = False day_type = "festive" lunch_time = None meeting_time =None Another example: switch tarot case 0: card = "Fool" case 1: card = "Alan Moore" case 2: card = "High Priestess" etc. -- https://mail.python.org/mailman/listinfo/python-list
Re: Unpacking U-Boot image file
On Wed, 09 Apr 2014 18:18:56 +0100, Rustom Mody wrote: On Wednesday, April 9, 2014 9:36:40 PM UTC+5:30, trewio wrote: How to extract files from U-Boot image file, LZMA-compressed? Is there a Python script that can do this properly? For lzma theres this (recent) python library https://docs.python.org/dev/library/lzma.html Though you might just be better off with the command-line xz unxz etc After that.. whats the U-boot format? The Fine Manual (http://www.denx.de/wiki/view/DULG/UBootImages) isn't very forthcoming, sadly; "U-Boot operates on "image" files which can be basically anything, preceeded by a special header; see the definitions in include/image.h for details; basically, the header defines the following image properties * Target Operating System * Target CPU Architecture * Compression Type * Load Address * Entry Point * Image Name * Image Timestamp" I suspect taking this apart may be a little involved. -- Rhodri James *-* Wildebeest Herder to the Masses -- https://mail.python.org/mailman/listinfo/python-list
Re: Method(s) called by square brackets, slice objects
On 4/10/2014 2:52 PM, John Ladasky wrote: Thanks to both Ethan and Steven for their replies. Steven: I was trying to use the interpreter and wasn't getting results that I understood -- because I didn't know that __getslice__ was simply gone in Python 3. I implemented a __getslice__ method in my subclass that never got called. Ethan: I saw that slice objects were being sent to __getitem__, but that confused me as I thought that its purpose, as implied by the method name, was to return a SINGLE item. A slice is a single sequence object. Sequences can result from any of index lookup, key lookup, or slicings. The backstory is that slicing originally supported only start and stop positions. The 3 __xyzslice__ had separate start and stop parameters instead of the 1 index/key parameter of __xyzitem__. Strides and the slice class were introduced for the benefit of numerical python. When they were 'mainstreamed' into regular python, the __xyzslice__ methods were deprecated (in 2.0) as a single slice object can just as well be passed to __xyzitem__. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Teaching python to non-programmers
On Thu, 10 Apr 2014 21:52:53 +0100, wrote: Just awesome, not only do we have double line spacing and single line paragraphs, we've also got top posting, oh boy am I a happy bunny :) I'll leave someone3 else to explain, I just can't be bothered. Do you get paid to be a jerk, or is it just for yuks? If the latter, you're not funny. It's called irony, and unfortunately Mark is reacting to an all-to-common situation that GoogleGroups foists on unsuspecting posters like yourself. It's the result of a fundamental clash of technological cultures; trying to impose a pretty web interface on a protocol defined to use unformatted plain text. It fails, inevitably, leaving us Usenet and mailing-list-based readers annoyed at being given something unreadable to deal with. Unsurprisingly, most of us don't bother, and won't have read more than the first couple of words of your original post. The wiki page https://wiki.python.org/moin/GoogleGroupsPython goes into some detail of what the rest of us find annoying, and how to fix the problems. I've left the double-spacing that you quoting Mark produced so you can see that part of the problem -- if you want to understand why it is so hated, imagine that done to a screenful of Python script, then quoted by a few more people on GG, until you're only getting half a dozen lines of code (or text) on the screen. That sort of thing is hard work to read, and not many bother, and yes, it really does happen. Top posting is generally poor netiquette, thank you for not doing it this time. Unfortunately you fell into another trap GG lays for you by not handling attributions properly. Or at all this time. I happen to remember that you were replying to Mark Lawrence (just in case it was impossible for me to guess from the subject matter :-), but if I hadn't remembered that, I wouldn't have known from the context without going and searching. Again, that's work many people won't bother putting in, making your post less likely to be read. Sorry your post was the straw to break the camel's back this week, but it is a complete pain to the rest of us. I have more than once considered getting my reader to automatically discard anything with "@googlegroups.com" in the message ID just to reduce the aggravation. -- Rhodri James *-* Wildebeest Herder to the Masses -- https://mail.python.org/mailman/listinfo/python-list
module version number support for semver.org
Hi,
what do you think about officially supporting Semantic Versioning?
( http://semver.org )
Semantic Versioning has gained a lot of attention in other programming
languages. Even though not officially supported, many python libraries use it
as well (just search the pypi listing for things like "-alpha" "-beta" "-dev"
"-pre" to get a rough idea). There even is a class handling Semantic Versioning
in pip already: pip.util.version.SemanticVersion .
I'd speak in favor of officially adding support for semantic versioning to the
python module versioning specs as a follow up to PEP 440
( http://legacy.python.org/dev/peps/pep-0440/ ).
I want to avoid the fruitless discussion about personal versioning scheme
preference.
My main point is: both schemes are widely used (even in the python world).
As far as i can see both schemes can just co-exist in the python world giving
us the benefits of both without hurting us.
Short re-cap of both versioning schemes
===
The current version format specified in PEP 440 [2] follows this pseudo format:
[N:]N(.N)*[{a|b|c|rc}N][.postN][.devN]
So python module version numbers look like (taken from [2]):
1.0.dev456
1.0a1
1.0a2.dev456
1.0a12.dev456
1.0a12
1.0b1.dev456
1.0b2
1.0b2.post345.dev456
1.0b2.post345
1.0c1.dev456
1.0c1
1.0
1.0.post456.dev34
1.0.post456
1.1.dev1
Semantic Versioning follows this pseudo format:
N.N.N(-((N)|([0-9A-Za-z-]+))(.((N)|([0-9A-Za-z-])+))*)?
Some examples in order (taken from http://semver.org ):
1.0.0-alpha
1.0.0-alpha.1
1.0.0-alpha.beta
1.0.0-beta
1.0.0-beta.2
1.0.0-beta.11
1.0.0-rc.1
1.0.0
Key differences
===
Semantic Versioning supports
- free-text pre-releases without version number such as '-alpha', '-pre' and
the very widely used '-dev' (after a release the next commit increases the
version number and appends the '-dev', which is only removed for the release).
- always has MAJOR.MINOR.PATCH, (so 3 relevant) numbers as version number and
offers guidelines which to change when.
Semantic Versioning does not support
- post-releases (a post release would be an increase of the PATCH number).
- special handling for '-dev', '-alpha', '-beta', '-gamma' or 'rc'.
Ideas to solve (cross scheme) comparisons
=
A version comparator could first try parsing both versions to be compared
according to the current scheme and if that fails try parsing them both as
SemanticVersions.
Switching from one version naming scheme to another should be discouraged at
least within the leading N parts at the change boundary staying the same. That
way comparisons between the naming schemes could be settled by comparing the
leading numerical parts of the version.
Cheers,
Jörn
--
https://mail.python.org/mailman/listinfo/python-list
the logical operation confused me
>>> "ok" or "not ok" 'ok' >>> "ok" and "not ok" 'not ok' >>> why "ok" or "not ok" output "ok" , "ok" and "not ok" output "not ok" ? -- https://mail.python.org/mailman/listinfo/python-list
Re: the logical operation confused me
On 4/10/2014 7:02 PM, length power wrote: >>> "ok" or "not ok" 'ok' >>> "ok" and "not ok" 'not ok' >>> why "ok" or "not ok" output "ok" , "ok" and "not ok" output "not ok" ? This is explained in our fine manual. https://docs.python.org/2/reference/expressions.html#boolean-operations -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: the logical operation confused me
On 04/10/2014 04:02 PM, length power wrote:
>>> "ok" or "not ok"
'ok'
>>> "ok" and "not ok"
'not ok'
>>>
why "ok" or "not ok" output "ok" , "ok" and "not ok" output "not ok" ?
You are probably confusing yourself with the string "not ok". That
string, and any other non-empty string is considered true
>>> bool("not ok")
True
>>> bool("ok")
True
perhaps you meant
>>> not "ok"
False
Once past that possible confusion, the return value of the *and* and
*or* operators are explained here:
https://docs.python.org/release/2.5.2/lib/boolean.html
Gary Herron
--
https://mail.python.org/mailman/listinfo/python-list
Re: the logical operation confused me
On Fri, 11 Apr 2014 07:02:33 +0800, length power wrote: "ok" or "not ok" > 'ok' "ok" and "not ok" > 'not ok' > why "ok" or "not ok" output "ok" , "ok" and "not ok" output "not ok" ? I believe that: [ (falsey condition) or ]* (first truthy condition) or (any condition) [ or (any condition) ]* will return (first truthy condition) whereas: (truthy condition) and [ (truthy condition) and ]* (last truthy condition) will return (last truthy condition) where "[ clause ]*" represents an optional clause that may be repeated any number of times, "any condition" may evaluate falsey or truthy, "first" and "last" relate to the position of the condition type in a left to right evaluation sequence. -- Denis McMahon, [email protected] -- https://mail.python.org/mailman/listinfo/python-list
Re: module version number support for semver.org
On 4/10/2014 6:45 PM, Jörn Hees wrote: what do you think about officially supporting Semantic Versioning? (http://semver.org ) It is a nice fantasy. Under "Why...?" the author, Tom Preston-Werner, says "A simple example will demonstrate how Semantic Versioning can make dependency hell a thing of the past. Consider a library called "Firetruck." It requires a Semantically Versioned package named "Ladder." At the time that Firetruck is created, Ladder is at version 3.1.0. Since Firetruck uses some functionality that was first introduced in 3.1.0, you can safely specify the Ladder dependency as greater than or equal to 3.1.0 but less than 4.0.0. Now, when Ladder version 3.1.1 and 3.2.0 become available, you can release them to your package management system and know that they will be compatible with existing dependent software." Except you cannot know. Even though Firetruck works with Ladder 3.1.0, one *cannot* know for sure that is will work with Ladder 3.1.1, let alone 3.2.0. 1. Python use patch (micro, .z) numbers for bug fixes. Tom specifies "backwards compatible bug fixes". There ain't no such thing. Bug fixes break code that depends on the bug. Such dependence may be unintentional and not known until a supposedly safe patch release breaks the code that uses it. 2. Accidents, including regressions, happen. In respone to FAQ "What do I do if I accidentally release a backwards incompatible change as a minor version?" (which probably happends with every x.y.0 CPython release), Tom says "As soon as you realize that you've broken the Semantic Versioning spec, fix the problem and release a new minor version that corrects the problem and restores backwards compatibility. Even under this circumstance, it is unacceptable to modify versioned releases. If it's appropriate, document the offending version and inform your users of the problem so that they are aware of the offending version." This is well and good, but it invalidates the claim that one can reliably depend and mechanically base action on future release numbers. The answer to "What if I inadvertently alter the public API in a way that is not compliant with the version number change?" has the same problem. This is not to say that Semver does not improve the situation when it can be used. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Language summit notes
Steven D'Aprano writes: > Today in Montreal Canada, there was a Language Summit to discuss the > future of Python. Some highlights: […] > More in this email thread here: > https://mail.python.org/pipermail/python-dev/2014-April/133873.html Thanks very much for this! Core development is important to the whole Python community, but time-consuming to keep abreast of. Summaries for general consumption are very helpful. -- \ “I thought I'd begin by reading a poem by Shakespeare, but then | `\ I thought ‘Why should I? He never reads any of mine.’” —Spike | _o__) Milligan | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
On 10/04/14 21:44, Marko Rauhamaa wrote: I'm happy that asyncio is happening after all these long years. It would be nice if it supported edge-triggered wakeups, but I suppose that isn't supported in all operating systems. I have an issue with the use of coroutines. I think they are to evil. When a man like David Beazley says this https://twitter.com/dabeaz/status/440214755764994048 there is something crazy going on. Sturla -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
On 11/04/14 01:51, Sturla Molden wrote: I have an issue with the use of coroutines. I think they are to evil. When a man like David Beazley says this https://twitter.com/dabeaz/status/440214755764994048 there is something crazy going on. And why did Python get this Tulip beast, instead of a simple libuv wrapper? Node.js has already proven what libuv can do. Sturla -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
On 4/10/2014 7:51 PM, Sturla Molden wrote: On 10/04/14 21:44, Marko Rauhamaa wrote: I'm happy that asyncio is happening after all these long years. It would be nice if it supported edge-triggered wakeups, but I suppose that isn't supported in all operating systems. I have an issue with the use of coroutines. I think they are to evil. I think 'magical' is the word you should be looking for. When a man like David Beazley says this https://twitter.com/dabeaz/status/440214755764994048 there is something crazy going on. There is understanding how to use them, and understanding how they work in this context. I suspect that DB was talking about the second, deeper level. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
python obfuscate
Hi all, Does python has any good obfuscate? Currently our company wanna release one product developed by python to our customer. But dont's wanna others see the py code. I googled for a while but mostly just say using pyc. Any better one? Our product is deployed on Linux bed. Thanks. Wesley -- https://mail.python.org/mailman/listinfo/python-list
Re: python obfuscate
Wesley writes: > Hi all, > Does python has any good obfuscate? Define “good obfuscate”. What is your goal? If it is to hide your program's secrets from others, then obfuscation isn't going to help: no matter how good it is, it still needs to be readable by the runtime on the machine. Moreover, the more effective the obfuscation, the less correspondence there is between the distributed code and the code ytou actually maintain. Attempting to debug problems will be infeasible, directly in proportion to how effective the obfuscation is. Before looking to obfuscate your code, first establish – beyond mere emotional conviction – that there actually is something in the code which is worth hiding from recipients. > Currently our company wanna release one product developed by python to > our customer. But dont's wanna others see the py code. That's impossible: the code is in the hands of the customer. If your threat model is “the person who possesses the code must not have access”, then you've lost, just as DRM is a failure. -- \ “People demand freedom of speech to make up for the freedom of | `\ thought which they avoid.” —Soren Aabye Kierkegaard (1813–1855) | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: python obfuscate
On 4/10/2014 6:29 PM, Wesley wrote: > Hi all, Does python has any good obfuscate? > > Currently our company wanna release one product developed by python > to our customer. But dont's wanna others see the py code. > > I googled for a while but mostly just say using pyc. Any better one? Does that work? If so, wouldn't that be a great solution? Toby -- https://mail.python.org/mailman/listinfo/python-list
Re: python obfuscate
pyc has weakness: 1. easy to decompile 2. python version related, e.g. pyc from py2.5 cannot be used to py2.7 bed 在 2014年4月11日星期五UTC+8上午9时48分04秒，Tobiah写道： > On 4/10/2014 6:29 PM, Wesley wrote: > > > Hi all, Does python has any good obfuscate? > > > > > > Currently our company wanna release one product developed by python > > > to our customer. But dont's wanna others see the py code. > > > > > > I googled for a while but mostly just say using pyc. Any better one? > > > > Does that work? If so, wouldn't that be a great solution? > > > > Toby -- https://mail.python.org/mailman/listinfo/python-list
Re: python obfuscate
Umm, just wanna make all .py files not human readable. Or, maybe need a tool like zend in php. 在 2014年4月11日星期五UTC+8上午9时41分11秒，Ben Finney写道： > Wesley writes: > > > > > Hi all, > > > Does python has any good obfuscate? > > > > Define “good obfuscate”. What is your goal? > > > > If it is to hide your program's secrets from others, then obfuscation > > isn't going to help: no matter how good it is, it still needs to be > > readable by the runtime on the machine. > > > > Moreover, the more effective the obfuscation, the less correspondence > > there is between the distributed code and the code ytou actually > > maintain. Attempting to debug problems will be infeasible, directly in > > proportion to how effective the obfuscation is. > > > > Before looking to obfuscate your code, first establish – beyond mere > > emotional conviction – that there actually is something in the code > > which is worth hiding from recipients. > > > > > Currently our company wanna release one product developed by python to > > > our customer. But dont's wanna others see the py code. > > > > That's impossible: the code is in the hands of the customer. If your > > threat model is “the person who possesses the code must not have > > access”, then you've lost, just as DRM is a failure. > > > > -- > > \ “People demand freedom of speech to make up for the freedom of | > > `\ thought which they avoid.” —Soren Aabye Kierkegaard (1813–1855) | > > _o__) | > > Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: python obfuscate
On Thu, Apr 10, 2014 at 7:48 PM, Tobiah wrote: > On 4/10/2014 6:29 PM, Wesley wrote: >> Hi all, Does python has any good obfuscate? >> >> Currently our company wanna release one product developed by python >> to our customer. But dont's wanna others see the py code. >> >> I googled for a while but mostly just say using pyc. Any better one? > > Does that work? If so, wouldn't that be a great solution? No, pyc files contain Python byte code, which can easily be disassembled -- in fact, the capacity to do this can be found in the "dis" module of the standard library. The result of disassembly is not valid Python, but it is not hard to read either. There are also decompilers available that can go the extra step and produce actual Python from the pyc file. -- https://mail.python.org/mailman/listinfo/python-list
Re: python obfuscate
On Thu, Apr 10, 2014 at 8:17 PM, Wesley wrote: > Umm, just wanna make all .py files not human readable. > > Or, maybe need a tool like zend in php. The only reliable way to prevent a customer from reverse-engineering your software is to not give them the software. For example, instead of giving them software containing the critical code that you want to protect, give them access to a web service running that code, which you host and control. This is true no matter what language you're using to write the software. -- https://mail.python.org/mailman/listinfo/python-list
Re: python obfuscate
Wesley writes: > Umm, just wanna make all .py files not human readable. (Please don't top-post; instead, use interleaved replies https://en.wikipedia.org/wiki/Posting_style#Interleaved_style> to make the conversation legible.) You want the code not readable by which humans? Any code which is readable by the machine is readable to the person who owns that machine, given enough effort of course. And any obfuscation needs to be reversed when the code is run, otherwise the machine reading it can't run it. So it seems you don't want obfuscation; you want to not distribute the code at all. -- \ “They who can give up essential liberty to obtain a little | `\temporary safety, deserve neither liberty nor safety.” | _o__) —Benjamin Franklin, 1775-02-17 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Teaching python to non-programmers
On Friday, April 11, 2014 4:10:22 AM UTC+5:30, Rhodri James wrote: > Sorry your post was the straw to break the camel's back this week, but it > is a complete pain to the rest of us. I have more than once considered > getting my reader to automatically discard anything with > "@googlegroups.com" in the message ID just to reduce the aggravation. I had a colleague at the university who had taught "System Programming" for the fifth year running. One day he confided to us (other colleagues): I think I am losing it... I am getting impatient and am inclined to tell the class: "Ive taught all this to you (so many times!) before Until I realize its not this class!! > The wiki page https://wiki.python.org/moin/GoogleGroupsPython goes into > some detail of what the rest of us find annoying, and how to fix the > problems. So we need to... (one of) - Patiently point out that link to each newcomer here - Silently put up - Express 'last straw' irritation and get called a jerk - Canvas with python list owners to stop GG - Canvas with Google to modify else shut down GG - Your choice here > I've left the double-spacing that you quoting Mark produced so > you can see that part of the problem -- if you want to understand why it > is so hated, imagine that done to a screenful of Python script, then > quoted by a few more people on GG, until you're only getting half a dozen > lines of code (or text) on the screen. That sort of thing is hard work to > read, and not many bother, and yes, it really does happen. Its no use. GG hides all the double-spaced, top-posted stuff in a very small font "show quoted text". If you want to show it more effectively you need to do something like this (or point to the mailing list archive) > On Thu, 10 Apr 2014 21:52:53 +0100, Pete Bee wrote: - - - - > - - >> - - >> Just awesome, not only do we have double line spacing and single line - - >> - - >> paragraphs, we've also got top posting, oh boy am I a happy bunny :) - - >> - - >> I'll leave someone3 else to explain, I just can't be bothered. - - >> - - >> - - > - - > Do you get paid to be a jerk, or is it just for yuks? If the latter, - - > you're not funny. - - - --- > Top posting is generally poor netiquette, thank you for not doing it this > time. There are cultures -- far more pervasive than USENET in 2014 -- where top posting is the norm, eg - Gmail makes top posting the norm. Compare the figures of gmail and Usenet users - Corporate cultures more or less require top posting -- helped by MS Outlook Else it looks like dishonesty/dissimulation/hiding - Personally I am on different groups. I tend to top post by default. And its as strange and bizarre there as its required minimum etiquette here > Unfortunately you fell into another trap GG lays for you by not > handling attributions properly. Or at all this time. [Personally] Double spacing bothers me least, top posting more, non/mis-attribution most -- https://mail.python.org/mailman/listinfo/python-list
Ostracising bad actors (was: Teaching python to non-programmers)
"Rhodri James" writes: > Sorry your post was the straw to break the camel's back this week, but > it is a complete pain to the rest of us. I have more than once > considered getting my reader to automatically discard anything with > "@googlegroups.com" in the message ID just to reduce the aggravation. I passed that threshold long ago. Posts that come to my Usenet client via Google Groups are automatically marked for deletion. I strongly recommend everyone do the same; and also to lobby for (and support) alternative Usenet interfaces which don't mangle the messages. -- \ “You know what would make a good story? Something about a clown | `\who makes people happy, but inside he's real sad. Also, he has | _o__) severe diarrhea.” —Jack Handey | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Unpacking U-Boot image file
On Friday, April 11, 2014 3:31:50 AM UTC+5:30, Rhodri James wrote: > On Wed, 09 Apr 2014 18:18:56 +0100, Rustom Mody > > After that.. whats the U-boot format? > > The Fine Manual (http://www.denx.de/wiki/view/DULG/UBootImages) isn't very > forthcoming, sadly; > > "U-Boot operates on "image" files which can be basically anything, > preceeded by a special header; see the definitions in include/image.h for > details; basically, the header defines the following image properties > > * Target Operating System > * Target CPU Architecture > * Compression Type > * Load Address > * Entry Point > * Image Name > * Image Timestamp" > > > I suspect taking this apart may be a little involved. If its a binary format, you (OP) may want to look at https://pypi.python.org/pypi/construct/2.5.1 Of course you will have to read/get the C struct and write the corresponding "Construct" You may want to ask on a U-boot forum for more details. -- https://mail.python.org/mailman/listinfo/python-list
Re: Teaching python to non-programmers
On Fri, Apr 11, 2014 at 1:17 PM, Rustom Mody wrote: > There are cultures -- far more pervasive than USENET in 2014 -- where > top posting is the norm, eg > - Gmail makes top posting the norm. Compare the figures of gmail and Usenet > users > - Corporate cultures more or less require top posting -- helped by MS Outlook > Else it looks like dishonesty/dissimulation/hiding > - Personally I am on different groups. I tend to top post by default. And its > as strange and bizarre there as its required minimum etiquette here I have seen plenty of cultures where people are unaware of the value of interleaved/bottom posting, but so far, not one where anyone has actually required it. Not one. "Norm" here just means "the thing people are too lazy to not do". That's not a reason for anyone else doing it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Teaching python to non-programmers
On Friday, April 11, 2014 9:29:00 AM UTC+5:30, Chris Angelico wrote: > On Fri, Apr 11, 2014 at 1:17 PM, Rustom Mody wrote: > > > There are cultures -- far more pervasive than USENET in 2014 -- where > > top posting is the norm, eg > > > - Gmail makes top posting the norm. Compare the figures of gmail and Usenet > > users > > - Corporate cultures more or less require top posting -- helped by MS > > Outlook > > Else it looks like dishonesty/dissimulation/hiding > > - Personally I am on different groups. I tend to top post by default. And > > its > > as strange and bizarre there as its required minimum etiquette here > > I have seen plenty of cultures where people are unaware of the value > of interleaved/bottom posting, but so far, not one where anyone has > actually required it. Not one. "Norm" here just means "the thing > people are too lazy to not do". That's not a reason for anyone else > doing it. Right. Its true that when I was at a fairly large corporate, I was not told: "Please always top post!" What I was very gently and super politely told was: "Please dont delete mail context" Now when a mail goes round between 5 persons and what is addressed at one point is not the immediate previous mail, bottom-posting without pruning is as meaningless as top posting. As in religion or any cultural matter, its fine to stand up for and even vociferously uphold one's 'own' whatever that may be. What is unhelpful is - to suggest that my norms are universal norms. IOW there is a fundamental difference between natural and human-made laws - to lose track of statistics, in this case the population-densities of USENET vs other internet-kiddie cultures -- https://mail.python.org/mailman/listinfo/python-list
Re: Teaching python to non-programmers
On Fri, Apr 11, 2014 at 2:37 PM, Rustom Mody wrote: > Right. Its true that when I was at a fairly large corporate, I was not told: > "Please always top post!" > > What I was very gently and super politely told was: > "Please dont delete mail context" Then you were told that by someone who does not understand email. That's equivalent to being told "Don't ever delete any of your code, just comment it out". I don't care who's saying that, it's bad advice. > Now when a mail goes round between 5 persons and what is addressed at one > point > is not the immediate previous mail, bottom-posting without pruning is as > meaningless as top posting. Yep. So you bottom-post *and prune*, because that is how email needs to be. You do not need to repeatedly send copies of the whole thread everywhere. > What is unhelpful is > - to suggest that my norms are universal norms. IOW there is a fundamental > difference between natural and human-made laws > - to lose track of statistics, in this case the population-densities of USENET > vs other internet-kiddie cultures Also unhelpful is to suggest that norms should, simply *because* they are the prevailing practice, be maintained. Even if everyone else on python-list top-posted, I would still bottom-post and trim. "Normal" is not a justification. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
On Friday, April 11, 2014 2:14:42 AM UTC+5:30, Marko Rauhamaa wrote: > Rustom Mody: > > > What you are saying is that what the OS is doing, you can do better. > > Analogous to said C programmer saying that what (data structures) the > > python programmer can make he can do better. > > > > I'm sorry, but I don't quite follow you there. Ok let me try again (Please note I am speaking more analogically than logically) There was a time -- say 1990 -- when there was this choice - use C -- a production language with half-assed data structures support - use Lisp -- strong support for data structures but otherwise unrealistic >From this world and its world view its natural to conclude that to choose a strong data structure supporting language is to choose an unrealistic language I was in the thick of this debate then http://www.the-magus.in/Publications/chor.pdf This argument is seen to be fallacious once we have languages like python (and Ruby and Java and Perl and Haskell and ...) Today we are in the same position vis-a-vis concurrency as we were with data structures in 1990. We have mainstream languages -- Java,C,C++,Python -- with half-assed concurrency support. And we have languages like Erlang, Go, Cloud Haskell which make concurrency center-stage but are otherwise lacking and unrealistic. I disagree with you in saying "We cant do better (than stay within the options offered by mainstream languages" As an individual you are probably right. >From a larger systemic pov (hopefully!) not! I disagree with Sturla in what is considered invariant and what is under one's control. He (seems?) to take hardware as under control, programming paradigm as not. I believe that the mileage that can be achieved by working on both is more than can be achieved by either alone. > I see the regular multithreaded approach as > (2) inviting race conditions carelessly--no mortal is immune. This I understand and concur with > > (1) oversimplification which makes it difficult to extend the design > and handle all of the real-world contingencies This I dont... -- https://mail.python.org/mailman/listinfo/python-list
Re: Teaching python to non-programmers
Chris Angelico writes: > On Fri, Apr 11, 2014 at 2:37 PM, Rustom Mody wrote: >> Right. Its true that when I was at a fairly large corporate, I was not told: >> "Please always top post!" >> >> What I was very gently and super politely told was: >> "Please dont delete mail context" > > Then you were told that by someone who does not understand email. It's not necessarily a bad idea to retain context in corporate emails. Messages tend to get forwarded to people other than the original recipient(s), and the context can be very helpful. But when you're posting to a mailing list or to a usenet group different considerations apply as there's usually a way of seeing the whole thread. Email is often a poor relatively poor medium for internal communication, because of this problem. Also people who might properly have a something useful to say on the subject matter may never get to see the email. A private news server or web forum is often better. That's not to say that there's no place for email in internal communication, but it's best reserved for occasions where confidentiality is required, or at least politic. -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
On Fri, 11 Apr 2014 01:51:41 +0200, Sturla Molden wrote: > On 10/04/14 21:44, Marko Rauhamaa wrote: >> I'm happy that asyncio is >> happening after all these long years. It would be nice if it supported >> edge-triggered wakeups, but I suppose that isn't supported in all >> operating systems. > > I have an issue with the use of coroutines. I think they are to evil. They are to evil ... as what? To evil as chalk is to cheese? Black is to white? Bees are to honey? I think coroutines are awesome, but like all advanced concepts, sometimes they can be abused, and sometimes they are hard to understand not because they are hard to understand in and of themselves, but because they are being used to do something inherently complicated. > When a man like David Beazley says this > > https://twitter.com/dabeaz/status/440214755764994048 > > there is something crazy going on. Good lord!!! David Beazley has been consumed by the Dark Side and uses Twitter??? There certainly is something crazy going on! -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Teaching python to non-programmers
On Thu, Apr 10, 2014 at 11:11 PM, Chris Angelico wrote: > On Fri, Apr 11, 2014 at 2:37 PM, Rustom Mody wrote: >> Right. Its true that when I was at a fairly large corporate, I was not told: >> "Please always top post!" >> >> What I was very gently and super politely told was: >> "Please dont delete mail context" > > Then you were told that by someone who does not understand email. > That's equivalent to being told "Don't ever delete any of your code, > just comment it out". I don't care who's saying that, it's bad advice. That depends on what the mail is being used for. For instance there's a difference between mail-as-dialogue and mail-as-business-process. In the former it is normal, even polite, to prune as the topic evolves and past quotations become less relevant. In the latter it seems more common for the entire thread to be preserved as a sort of "chain of custody" -- this way the next person who needs to see the email thread has full context as to what needs to happen and where the request is coming from. I'm generally in the habit of not pruning work-related emails even when they are more of the dialogue type, because these tend to be very tightly focused, and so that if a new person needs to be brought into the conversation they will have the full context of what we're talking about and why we're talking about it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Teaching python to non-programmers
On Fri, Apr 11, 2014 at 3:34 PM, Paul Rudin wrote:
> Chris Angelico writes:
>
>> On Fri, Apr 11, 2014 at 2:37 PM, Rustom Mody wrote:
>>> What I was very gently and super politely told was:
>>> "Please dont delete mail context"
>>
>> Then you were told that by someone who does not understand email.
>
> It's not necessarily a bad idea to retain context in corporate
> emails. Messages tend to get forwarded to people other than the original
> recipient(s), and the context can be very helpful.
A good mail client will let you forward an entire thread all at once.
That covers the use-case without polluting *every single email ever
sent* with the entire history. Plus, a decent client should let you
forward some without others, which would mean you don't have the
awkward situation of sending someone all the internal discussion
("just send this guy the standard cockroach letter") that led to the
final decision.
Retaining context should either be done with an internal wiki or
forum, or by reading up in the retained emails. You don't need to
duplicate all context every post in any medium.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Teaching python to non-programmers
On Friday, April 11, 2014 10:41:26 AM UTC+5:30, Chris Angelico wrote: > On Fri, Apr 11, 2014 at 2:37 PM, Rustom Mody wrote: > > Right. Its true that when I was at a fairly large corporate, I was not told: > > "Please always top post!" > > > > What I was very gently and super politely told was: > > "Please dont delete mail context" > > Then you were told that by someone who does not understand email. In middle-eastern society women are expected to dress heavier than in the West. A few years ago a girl went to school in France with a scarf and she was penalized. You seem to be cocksure who is right. Im just curious who you think it is :-) People whose familiarity with religion is limited to the Judeo-Christian tradition are inclined to the view (usually implicit) that "being religious" == "belief in God" However there are religions where belief in God is irreligious -- Jainism And others where it is is irrelevant -- Tao, Shinto. [There is the story of a westerner who wen to a shinto temple and said: All this (rites) is fine and beautiful but what's your *philosophy* To which he was told: "Philosophy? We have no philosophy! We dance!"] > > That's equivalent to being told "Don't ever delete any of your code, > just comment it out". I don't care who's saying that, it's bad advice. The correct analogy: "Dont ever delete content from the repository" > > > Now when a mail goes round between 5 persons and what is addressed at one > > point > > is not the immediate previous mail, bottom-posting without pruning is as > > meaningless as top posting. > > > Yep. So you bottom-post *and prune*, because that is how email needs > to be. You do not need to repeatedly send copies of the whole thread > everywhere. > > > > What is unhelpful is > > - to suggest that my norms are universal norms. IOW there is a fundamental > > difference between natural and human-made laws > > - to lose track of statistics, in this case the population-densities of > > USENET > > vs other internet-kiddie cultures > > > > Also unhelpful is to suggest that norms should, simply *because* they > are the prevailing practice, be maintained. Even if everyone else on > python-list top-posted, I would still bottom-post and trim. "Normal" > is not a justification. Ok no argument here. On the python list that is the norm. Most people who are first timers have no clue about that norm. -- https://mail.python.org/mailman/listinfo/python-list
Re: python obfuscate
On 11/04/2014 04:12, Ben Finney wrote: Wesley writes: Umm, just wanna make all .py files not human readable. (Please don't top-post; instead, use interleaved replies https://en.wikipedia.org/wiki/Posting_style#Interleaved_style> to make the conversation legible.) Further would you please use the mailing list https://mail.python.org/mailman/listinfo/python-list or read and action this https://wiki.python.org/moin/GoogleGroupsPython to prevent us seeing double line spacing and single line paragraphs, thanks. -- 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: Teaching python to non-programmers
On Fri, Apr 11, 2014 at 3:39 PM, Ian Kelly wrote: > That depends on what the mail is being used for. For instance there's > a difference between mail-as-dialogue and mail-as-business-process. > In the former it is normal, even polite, to prune as the topic evolves > and past quotations become less relevant. In the latter it seems more > common for the entire thread to be preserved as a sort of "chain of > custody" -- this way the next person who needs to see the email thread > has full context as to what needs to happen and where the request is > coming from. Sounds like a job for an internal wiki, actually. Have you ever gone back through a fifty-post thread, reading through its entire unpruned context to find something? And if you have, was it at all practical? Somehow I doubt it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Teaching python to non-programmers
On Friday, April 11, 2014 11:12:14 AM UTC+5:30, Rustom Mody wrote: > On Friday, April 11, 2014 10:41:26 AM UTC+5:30, Chris Angelico wrote: > > Also unhelpful is to suggest that norms should, simply *because* they > > are the prevailing practice, be maintained. Even if everyone else on > > python-list top-posted, I would still bottom-post and trim. "Normal" > > is not a justification. > > Ok no argument here. > On the python list that is the norm. > Most people who are first timers have no clue about that norm. Just to make it clear: 1. I have no objection to the python list culture. As I said I tend to follow it in places where it is not the norm and get chided for it [For the record on other groups which are exclusively GG/gmail based Ive been told that because I am geek/nerd I do it in a strange way] 2. Nor to people getting irritated with others not following it and telling them off What I am pointing out is that if one gets so besotted with irritation as to lose coherence, its unlikely that any useful communication will ensue. -- https://mail.python.org/mailman/listinfo/python-list
Re: Teaching python to non-programmers
On Fri, Apr 11, 2014 at 3:42 PM, Rustom Mody wrote: > People whose familiarity with religion is limited to the Judeo-Christian > tradition are inclined to the view (usually implicit) that > "being religious" == "belief in God" > However there are religions where belief in God is irreligious -- Jainism > And others where it is is irrelevant -- Tao, Shinto. > [There is the story of a westerner who wen to a shinto temple and said: > All this (rites) is fine and beautiful but what's your *philosophy* > To which he was told: "Philosophy? We have no philosophy! We dance!"] That's nothing to do with norms, though. The norm might be to follow Taoism, but that doesn't make it more right - just more normal. >> That's equivalent to being told "Don't ever delete any of your code, >> just comment it out". I don't care who's saying that, it's bad advice. > > The correct analogy: "Dont ever delete content from the repository" Generally, a repository won't let you truly delete anything, which is exactly my point: you can delete lines of code from the current file without losing anything. If you want to see the context, you go and look at context, you don't need it to be right there in the current file. Same with email - and often even easier, because your client will let you simply scroll up and see what was said previously. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python obfuscate
On 11 April 2014 02:29, Wesley wrote: > Does python has any good obfuscate? Most other people on the list will point out why such a thing is mostly pointless and you don't really need it. However, if this really is your major blocker to using Python, I suggest compiling with Cython. There are downsides, but untyped Cython basically compiles the bytecode into C without actually changing the program, making compatibility really good. It's very difficult to reverse-engineer, largely because there aren't specialised tools to do it. But I do warn that it's adding another abstracting step that doesn't improve - it probably harms - the overall usability of the product. Further, a determined hacker can circumvent it, much as they can circumvent everything else. -- https://mail.python.org/mailman/listinfo/python-list
Re: Teaching python to non-programmers
On Fri, Apr 11, 2014 at 3:54 PM, Rustom Mody wrote: > Just to make it clear: > 1. I have no objection to the python list culture. > As I said I tend to follow it in places where it is not the norm and get > chided for it > [For the record on other groups which are exclusively GG/gmail based Ive > been > told that because I am geek/nerd I do it in a strange way] > 2. Nor to people getting irritated with others not following it and telling >them off > > What I am pointing out is that if one gets so besotted with irritation as to > lose coherence, its unlikely that any useful communication will ensue. Then be the geek/nerd. Do something more useful. See how many people start finding that it's actually the better way. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python obfuscate
On Fri, Apr 11, 2014 at 4:00 PM, Joshua Landau wrote: > But I do warn that it's adding another abstracting step that > doesn't improve - it probably harms - the overall usability of the > product. Further, a determined hacker can circumvent it, much as they > can circumvent everything else. I had this argument with my boss at work about obfuscating our JavaScript code. He said that he was extremely concerned that nobody should be able to rip off all his code; I said that anybody could still rip it off, just by using the code exactly the way the browser would. The *ONLY* advantage you can possibly get from an obfuscation system is that your users can't easily figure out what's going on internally; they can still, by definition, run the program unchanged. If you run obfuscated code through a prettifier (or a decompiler and then a prettifier, as the case may be), you end up with something that's practically indistinguishable from poorly-commented code. Sure, it's not as nice to work with as something with helpful variable names and comments, but it's far from impossible. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: so module loading fails
Eddy Ilg writes: > ... > > Checking the symbols of Entity.so gives: > # nm Entity.so | grep PyInit_Entity > 1e5c t PyInit_Entity When I remember right, "t" means a "local" (aka "static") symbol - you need instead a "global" symbol (identified by "T"). -- https://mail.python.org/mailman/listinfo/python-list
