ANN: eGenix mxODBC 3.2.2 - Python ODBC Database Interface
ANNOUNCING eGenix.com mxODBC Python ODBC Database Interface Version 3.2.2 mxODBC is our commercially supported Python extension providing ODBC database connectivity to Python applications on Windows, Mac OS X, Unix and BSD platforms This announcement is also available on our web-site for online reading: http://www.egenix.com/company/news/eGenix-mxODBC-3.2.2-GA.html INTRODUCTION mxODBC provides an easy-to-use, high-performance, reliable and robust Python interface to ODBC compatible databases such as MS SQL Server, MS Access, Oracle Database, IBM DB2 and Informix , Sybase ASE and Sybase Anywhere, MySQL, PostgreSQL, SAP MaxDB and many more: http://www.egenix.com/products/python/mxODBC/ The "eGenix mxODBC - Python ODBC Database Interface" product is a commercial extension to our open-source eGenix mx Base Distribution: http://www.egenix.com/products/python/mxBase/ NEWS The 3.2.2 release of our mxODBC is the latest patch level release of our popular Python ODBC Interface. In this release, we've included the following the following enhancements and fixes: Feature Enhancements * Backported the new .cursortype attribute from the upcoming mxODBC 3.3. The new attribute allows easily adjusting and inspecting the ODBC cursor type to be used for an mxODBC cursor object. The reason for this unusual backport and inclusion in a patch level release is that we found a serious performance issue with MS SQL Server when using it with mxODBC 3.2 (see below). This needed to be addressed immediately. Driver Compatibility * MS SQL Server performance can now be much enhanced, and increased to levels beyond that of mxODBC 3.1 and previous releases, by adjusting the default cursor type to forward-only cursors: connection = mx.ODBC.Windows.DriverConnect(...) connection.cursortype = mx.ODBC.Windows.SQL.CURSOR_FORWARD_ONLY # Cursors created on this connection will then default to forward # only cursors, instead of the mxODBC 3.2 default for SQL Server # of using static cursors cursor = connection.cursor() The performance increase compared to mxODBC 3.2.1 is enormous: from 2-3x faster executes/fetches for average queries, up to 300x faster for simple cases. In mxODBC 3.3, we will switch to using forward-only cursors per default for all database backends. * IBM DB2 can benefit from the same performance enhancements using forward-only cursors. The effect is a lot smaller, but still noticeable: up to 2x faster executes/fetches with forward-only cursors, compared to mxODBC 3.2.1. * Added documentation to explain the different cursor types, compatibility with different database backends and effects on performance. Fixes - * Fixed a problem with using mxODBC cursors as context managers: these worked fine in Python 2.6, but had stopped working in Python 2.7 due to changes in the Python internals. For the full set of changes please check the mxODBC change log: http://www.egenix.com/products/python/mxODBC/changelog.html FEATURES mxODBC 3.2 was released on 2012-08-28. Please see the full announcement for highlights of the 3.2 release: http://www.egenix.com/company/news/eGenix-mxODBC-3.2.2-GA.html For the full set of features mxODBC has to offer, please see: http://www.egenix.com/products/python/mxODBC/#Features EDITIONS mxODBC is available in these three editions: * The low-cost Standard Edition which provides data connectivity to a single database type, e.g. just MS SQL Server. * The Professional Edition, which gives full access to all mxODBC features. * The Product Development Edition, which allows including mxODBC in applications you develop. Compared to mxODBC 3.0, we have simplified our license terms to clarify the situation on multi-core and virtual machines. In most cases, you no longer need to purchase more than one license per processor or virtual machine, scaling down the overall license costs significantly compared to earlier mxODBC releases. For a complete overview of the new editions, please see the product page. http://www.egenix.com/products/python/mxODBC/#mxODBCEditions DOWNLOADS The download archives and instructions for installing the package can be found at: http://www.egenix.com/products/python/mxODBC/ In order to use the eGenix mxODBC package you will first need to install
Python 2.7.3 tempfile.py, ln34, from random import Random as _Random
In Python 2.7.3, at ln34 the source file tempfile.py states: from random import Random as _Random But, Random is a Class. The project imports werkzeug and using PyInstaller, the Traceback is: Traceback (most recent call last): File "", line 9, in File "/home/ubuntu/Programs/pyinstaller-2.0/PyInstaller/loader/pyi_importers.py", line 404, in load_module module = imp.load_module(fullname, fp, filename, self._c_ext_tuple) File "xserver.pyx", line 18, in init xserver (//home//ubuntu//Programs//myproject//myproject_pyx/xserver.c:2481) File "/home/ubuntu/Programs/pyinstaller-2.0/PyInstaller/loader/pyi_importers.py", line 268, in load_module exec(bytecode, module.__dict__) File "//home//ubuntu//Programs//myproject//myproject_pi2/build/pyi.linux2/myproject/out00-PYZ.pyz/werkzeug.wrappers", line 26, in File "/home/ubuntu/Programs/pyinstaller-2.0/PyInstaller/loader/pyi_importers.py", line 268, in load_module exec(bytecode, module.__dict__) File "//home//ubuntu//Programs//myproject//myproject_pi2/build/pyi.linux2/myproject/out00-PYZ.pyz/werkzeug.http", line 25, in File "/home/ubuntu/Programs/pyinstaller-2.0/PyInstaller/loader/pyi_importers.py", line 268, in load_module exec(bytecode, module.__dict__) File "//home//ubuntu//Programs//myproject//myproject_pi2/build/pyi.linux2/myproject/out00-PYZ.pyz/urllib2", line 94, in File "/home/ubuntu/Programs/pyinstaller-2.0/PyInstaller/loader/pyi_importers.py", line 268, in load_module exec(bytecode, module.__dict__) File "//home//ubuntu//Programs//myproject//myproject_pi2/build/pyi.linux2/myproject/out00-PYZ.pyz/httplib", line 79, in File "/home/ubuntu/Programs/pyinstaller-2.0/PyInstaller/loader/pyi_importers.py", line 268, in load_module exec(bytecode, module.__dict__) File "//home//ubuntu//Programs//myproject//myproject_pi2/build/pyi.linux2/myproject/out00-PYZ.pyz/mimetools", line 6, in File "/home/ubuntu/Programs/pyinstaller-2.0/PyInstaller/loader/pyi_importers.py", line 268, in load_module exec(bytecode, module.__dict__) File "//home//ubuntu//Programs//myproject//myproject_pi2/build/pyi.linux2/myproject/out00-PYZ.pyz/tempfile", line 34, in ImportError: cannot import name Random Is this a bug? Or, is there some workaround available? Thx. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.7.3 tempfile.py, ln34, from random import Random as _Random
dbv wrote: > In Python 2.7.3, at ln34 the source file tempfile.py states: > > from random import Random as _Random > > But, Random is a Class. This is not a problem. You can import arbitrary objects from a module. > The project imports werkzeug and using PyInstaller, the Traceback is: > > Traceback (most recent call last): > File "", line 9, in > File [...] > line 268, in load_module > exec(bytecode, module.__dict__) > File > "//home//ubuntu//Programs//myproject//myproject_pi2/build/pyi.linux2/myproject/out00- PYZ.pyz/tempfile", > line 34, in > ImportError: cannot import name Random > > Is this a bug? Or, is there some workaround available? Thx. I don't know about PyInstaller or werkzeug, but the most likely cause is that you shaded the standard library's random module with your own random.py which doesn't contain an object named "Random". Here's a demonostration: Normal behaviour: $ python -c 'from random import Random as _Random' Now add an empty random.py: $ touch random.py $ python -c 'from random import Random as _Random' Traceback (most recent call last): File "", line 1, in ImportError: cannot import name Random Back to normal: $ rm random.pyc random.py $ python -c 'from random import Random as _Random' -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.7.3 tempfile.py, ln34, from random import Random as _Random
On 03/25/2013 08:29 AM, dbv wrote: In Python 2.7.3, at ln34 the source file tempfile.py states: from random import Random as _Random But, Random is a Class. Have you just tried the following: import random print dir(random.random) print random.__file__ I suspect you have another random.py (or equivalent) in your sys.path -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.7.3 tempfile.py, ln34, from random import Random as _Random
I have a number of .py source files and one source file has an "import random" and another has "import werkzeug". The project works perfectly in the Python interpreter. Problem appears when using PyInstaller. How do get out of jail? -- http://mail.python.org/mailman/listinfo/python-list
Re: Separate Rows in reader
On Mar 25, 11:52 am, Jiewei Huang wrote:
> On Sunday, March 24, 2013 9:10:45 PM UTC+10, ypsun wrote:
> > Jiewei Huang於 2013年3月24日星期日UTC+1上午6時20分29秒寫道：
>
> > > Hi all,
>
> > > Currently create a simple text-based database of information about people
>
> > > I have a csv file which consist of 3 rows , row 1 2 and 3 is as such:
>
> > > Name Address Telephone Birthday
>
> > > John Konon Ministry of Moon Walks 4567882 27-Feb
>
> > > Stacy Kisha Ministry of Man Power 1234567 17-Jan
>
> > > My codes are :
>
> > > import csv
>
> > > original = file('friends.csv', 'rU')
>
> > > reader = csv.reader(original)
>
> > > for row in reader:
>
> > > print row
>
> > > and the output is :
>
> > > ['Name', ' Address', 'Telephone', 'Birthday']
>
> > > ['John Konon', 'Ministry of Moon Walks', '4567882', '27-Feb']
>
> > > ['Stacy Kisha', 'Ministry of Man Power', '1234567', '17-Jan']
>
> > > But i wanted to make it
>
> > > [('John Cleese', 'Ministry of Silly Walks', '421', '27-Feb'),
>
> > > ( 'Stacy Kisha', 'Ministry of Man Power', '1234567', 17-Jan')]
>
> > > can someone show me guidance to this issue
>
> > > Thanks all
>
> > import csv
>
> > original = file('friends.csv', 'rU')
>
> > reader = csv.reader(original)
>
> > print [tuple(row) for row in reader][1:]
>
> > is this you want?
>
> > Note that:
>
> > 1) I assume your csv file content are seperated by comma
>
> > 2) this way allocates your memory, will be a trouble when a big table :P
>
> Hi guys, i got into another situation i was told not to use csv library and
> currently my code is :
>
> f = open('friends.csv', 'rU')
> for row in f:
>
> print [row for (row) in f]
>
> output :
> ['John Cleese,Ministry of Silly Walks,421,27-Oct\n', 'Stacy
> Kisha,Ministry of Man Power,1234567,17-Jan\n']
>
> i need it to become :
> [('John Cleese', 'Ministry of Silly Walks', '421', '27-Oct'), ('Stacy
> Kisha', 'Ministry of Man Power', '1234567', '17-Jan')]
>
> guide me please
Have you tried the split (and perhaps strip) methods from
http://docs.python.org/2/library/stdtypes.html#string-methods
?
--
http://mail.python.org/mailman/listinfo/python-list
Help me pick an API design (OO vs functional)
Hello everyone,
my name is Michael, I'm the lead developer of a Python GUI automation library
for Windows called Automa: http://www.getautoma.com. We want to add some
features to our library but are unsure how to best expose them via our API. It
would be extremely helpful for us if you could let us know which API design
feels "right" to you.
Our API already offers very simple commands for automating the GUI of a Windows
computer. For example:
from automa.api import *
start("Notepad")
write("Hello World!")
press(CTRL + 's')
write("test.txt", into="File name")
click("Save")
click("Close")
When you execute this script, Automa starts Notepad and simulates key strokes,
mouse movements and clicks to perform the required commands. At the moment,
each action is performed in the currently active window.
We do not (yet) have a functionality that allows you to explicitly switch to a
specific window. Such a functionality would for instance make it possible to
open two Notepad windows using the start(...) command, and copy text between
them.
One API design would be to have our start(...) function return a "Window" (say)
object, whose methods allow you to do the same operations as the global
functions write(...), press(...), click(...) etc., but in the respective
window. In this design, the example of operating two Notepad windows could be
written as
notepad_1 = start("Notepad")
notepad_2 = start("Notepad")
notepad_1.write("Hello World!")
notepad_1.press(CTRL + 'a', CTRL + 'c')
notepad_2.press(CTRL + 'v')
The problem with this design is that it effectively duplicates our API: We want
to keep our "global" functions because they are so easy to read. If we add
methods to a new "Window" class that do more or less the same, we feel that we
are violating Python's principle that "There should be one - and preferably
only one - obvious way to do it."
An alternative design would be to make the window switching an explicit action.
One way of doing this would be to add a new global function, say "switch_to" or
"activate", that takes a single parameter that identifies the window to be
switched to. We could still have start(...) return a Window object, that could
then be passed to our function:
notepad_1 = start("Notepad")
notepad_2 = start("Notepad")
switch_to(notepad_1)
write("Hello World!")
press(CTRL + 'a', CTRL + 'c')
switch_to(notepad_2)
press(CTRL + 'v')
Maybe our Window objects could also be used as context managers:
notepad_1 = start("Notepad")
notepad_2 = start("Notepad")
with notepad_1:
write("Hello World!")
press(CTRL + 'a', CTRL + 'c')
with notepad_2:
press(CTRL + 'v')
As a final idea, switching could also be done as a method of the Window class:
notepad_1 = start("Notepad")
notepad_2 = start("Notepad")
notepad_1.activate()
write("Hello World!")
press(CTRL + 'a', CTRL + 'c')
notepad_2.activate()
press(CTRL + 'v')
It would be extremely helpful for us if you could let me know which way of
using the API you would prefer. If you opt for an explicit version, how would
you call the respective method? "activate" / "switch_to" / "focus" or something
else?
Thank you so much!
Best wishes,
Michael
--
http://mail.python.org/mailman/listinfo/python-list
Python 2.7.3 + Docutils + Cygwin = Aborted?
I've asked this question on the Docutils list but there seems to be no obvious Docutils problem, so I'll ask here If I do this: python rst2latex.py foo.latex It works BUT python ends with an "Aborted" message and an empty python2.7.exe.stackdump. The practical problem here is that the python abort is causing the makefile that drives the whole process to stop. The same thing works fine with the same input file on FreeBSD or Linux. Is there a known Cygwin python 2.7 interaction issue? -- --- Tim Daneliuk -- http://mail.python.org/mailman/listinfo/python-list
Re: Help me pick an API design (OO vs functional)
On Mon, Mar 25, 2013 at 8:29 PM, Michael Herrmann
wrote:
> notepad_1 = start("Notepad")
> notepad_2 = start("Notepad")
> notepad_1.write("Hello World!")
> notepad_1.press(CTRL + 'a', CTRL + 'c')
> notepad_2.press(CTRL + 'v')
Explicit is better than implicit. Changing windows should be explicit
and not implified by your library.
> notepad_1 = start("Notepad")
> notepad_2 = start("Notepad")
> switch_to(notepad_1)
> write("Hello World!")
> press(CTRL + 'a', CTRL + 'c')
> switch_to(notepad_2)
> press(CTRL + 'v')
Much better.
> notepad_1 = start("Notepad")
> notepad_2 = start("Notepad")
> with notepad_1:
> write("Hello World!")
> press(CTRL + 'a', CTRL + 'c')
> with notepad_2:
> press(CTRL + 'v')
That’s ugly, and don’t forget that your users aren’t Pythonistas most
of the time.
> notepad_1 = start("Notepad")
> notepad_2 = start("Notepad")
> notepad_1.activate()
> write("Hello World!")
> press(CTRL + 'a', CTRL + 'c')
> notepad_2.activate()
> press(CTRL + 'v')
That is nice and makes sense, because a global function feels wrong,
at least for me.
> It would be extremely helpful for us if you could let me know which way of
> using the API you would prefer. If you opt for an explicit version, how would
> you call the respective method? "activate" / "switch_to" / "focus" or
> something else?
Window().focus() is the best IMO.
PS. do you plan a version for non-Windows OSes? Also, €99 is too expensive.
--
Kwpolska | GPG KEY: 5EAAEA16
stop html mail| always bottom-post
http://asciiribbon.org| http://caliburn.nl/topposting.html
--
http://mail.python.org/mailman/listinfo/python-list
How to define "exec" method on a class object? Get syntax error due to built in command
I am using swig to generate our CLI for TCL and Python. In this CLI, we have a
subcommand "exec" that is failing to compile in the python case. There seems to
be some built-in python command "exec" which is giving a syntax error in the
.py file generated by swig when I try to import it:
def exec(*args): return _wbt_daemon.dm_cli_exec(*args)
^
SyntaxError: invalid syntax
I don't really want to change the CLI commands or make them different between
languages. Is there any way to define a method called "exec" on a class? It
would be executed as obj.exec() so I don't see why it should conflict with the
built in "exec" command.
class dm_cli(_object):
__swig_setmethods__ = {}
__setattr__ = lambda self, name, value: _swig_setattr(self, dm_cli, name,
value)
__swig_getmethods__ = {}
__getattr__ = lambda self, name: _swig_getattr(self, dm_cli, name)
def __init__(self): raise RuntimeError, "No constructor defined"
...
def exec(*args): return _wbt_daemon.dm_cli_exec(*args)
...
}
--
http://mail.python.org/mailman/listinfo/python-list
Re: Help me pick an API design (OO vs functional)
Hi Kwpolska,
thanks for your reply (as last time I posted here!).
On Monday, March 25, 2013 8:42:25 PM UTC+1, Kwpolska wrote:
> ...
>
> > notepad_1 = start("Notepad")
> > notepad_2 = start("Notepad")
> > with notepad_1:
> > write("Hello World!")
> > press(CTRL + 'a', CTRL + 'c')
> > with notepad_2:
> > press(CTRL + 'v')
>
> That’s ugly, and don’t forget that your users aren’t Pythonistas most
> of the time.
I kind of like the context manager solution because the indentation makes it
very obvious what happens in which window. You are right about our target group
though. Also, the "with" is not as explicit as it probably should be.
> ...
> PS. do you plan a version for non-Windows OSes? Also, €99 is too expensive.
We'd of course love to support other platforms but don't currently have the
resources to do this. We actually just wrote a blog entry about this and some
related questions: http://www.getautoma.com/blog/automa-faq If we have
something wrong, do let us know in the comments over there!
It's very hard work building such an automation tool and also we have to live
off something. Unfortunately, we can't make the price any lower.
P.S.: First-time bottom-posting!
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to define "exec" method on a class object? Get syntax error due to built in command
On Tue, Mar 26, 2013 at 7:28 AM, Kyle wrote: > I am using swig to generate our CLI for TCL and Python. In this CLI, we have > a subcommand "exec" that is failing to compile in the python case. There > seems to be some built-in python command "exec" which is giving a syntax > error in the .py file generated by swig when I try to import it: > >def exec(*args): return _wbt_daemon.dm_cli_exec(*args) In Python 2, exec is a keyword, so you can't do that. In Python 3, exec is simply a built-in function, so it'd work fine. Technically you can get around the problem in 2.x with setattr/getattr, but that may not really be all that useful... def _exec(*args): return _wbt_daemon.dm_cli_exec(*args) ... setattr(dm_cli,"exec",dm_cli._exec) Tested on 2.6 for Windows (I really ought to get myself a 2.7, maybe when 2.7.4 gets released I'll grab it). ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Help me pick an API design (OO vs functional)
On Tue, Mar 26, 2013 at 7:48 AM, Michael Herrmann
wrote:
> On Monday, March 25, 2013 8:42:25 PM UTC+1, Kwpolska wrote:
>> ...
>>
>> > notepad_1 = start("Notepad")
>> > notepad_2 = start("Notepad")
>> > with notepad_1:
>> > write("Hello World!")
>> > press(CTRL + 'a', CTRL + 'c')
>> > with notepad_2:
>> > press(CTRL + 'v')
>>
>> That’s ugly, and don’t forget that your users aren’t Pythonistas most
>> of the time.
>
> I kind of like the context manager solution because the indentation makes it
> very obvious what happens in which window. You are right about our target
> group though. Also, the "with" is not as explicit as it probably should be.
What happens at the __exit__ of the context manager? What happens if
context managers are nested? I'd be inclined to the simpler option of
an explicit switch (since focus doesn't really "stack" and it'd feel
weird for focus to *sometimes* switch away when you're done working
with one window), though the context manager syntax does have its
advantages too.
>> PS. do you plan a version for non-Windows OSes? Also, €99 is too expensive.
>
> We'd of course love to support other platforms but don't currently have the
> resources to do this. We actually just wrote a blog entry about this and some
> related questions: http://www.getautoma.com/blog/automa-faq If we have
> something wrong, do let us know in the comments over there!
Make the API clean enough and someone else might well write a Linux
equivalent. Then it'll be as simple as a try/import/except/import at
the top and multiple platforms will work.
> P.S.: First-time bottom-posting!
Congrats! Feels good, doesn't it :)
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Performance of int/long in Python 3
The Python 3 merge of int and long has effectively penalized
small-number arithmetic by removing an optimization. As we've seen
from PEP 393 strings (jmf aside), there can be huge benefits from
having a single type with multiple representations internally. Is
there value in making the int type have a machine-word optimization in
the same way?
The cost is clear. Compare these methods for calculating the sum of
all numbers up to 65535, which stays under 2^31:
def range_sum(n):
return sum(range(n+1))
def forloop(n):
tot=0
for i in range(n+1):
tot+=i
return tot
def forloop_offset(n):
tot=1000
for i in range(n+1):
tot+=i
return tot-1000
import timeit
import sys
print(sys.version)
print("inline: %d"%sum(range(65536)))
print(timeit.timeit("sum(range(65536))",number=1000))
for func in ['range_sum','forloop','forloop_offset']:
print("%s: %r"%(func,(globals()[func](65535
print(timeit.timeit(func+"(65535)","from __main__ import
"+func,number=1000))
Windows XP:
C:\>python26\python inttime.py
2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)]
inline: 2147450880
2.36770455463
range_sum: 2147450880
2.61778550067
forloop: 2147450880
7.91409131608
forloop_offset: 2147450880L
23.3116954809
C:\>python33\python inttime.py
3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit (Intel)]
inline: 2147450880
5.25038713020789
range_sum: 2147450880
5.412975112758745
forloop: 2147450880
17.875799577879313
forloop_offset: 2147450880
19.31672544974291
Debian Wheezy:
rosuav@sikorsky:~$ python inttime.py
2.7.3 (default, Jan 2 2013, 13:56:14)
[GCC 4.7.2]
inline: 2147450880
1.92763710022
range_sum: 2147450880
1.93409109116
forloop: 2147450880
5.14633893967
forloop_offset: 2147450880
5.13459300995
rosuav@sikorsky:~$ python3 inttime.py
3.2.3 (default, Feb 20 2013, 14:44:27)
[GCC 4.7.2]
inline: 2147450880
2.884124994277954
range_sum: 2147450880
2.6586129665374756
forloop: 2147450880
7.660192012786865
forloop_offset: 2147450880
8.11817193031311
On 2.6/2.7, there's a massive penalty for switching to longs; on
3.2/3.3, the two for-loop versions are nearly identical in time.
(Side point: I'm often seeing that 3.2 on Linux is marginally faster
calling my range_sum function than doing the same thing inline. I do
not understand this. If anyone can explain what's going on there, I'm
all ears!)
Python 3's int is faster than Python 2's long, but slower than Python
2's int. So the question really is, would a two-form representation be
beneficial, and if so, is it worth the coding trouble?
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Help me pick an API design (OO vs functional)
On 03/25/2013 12:29 PM, Michael Herrmann wrote:
Hello everyone,
my name is Michael, I'm the lead developer of a Python GUI automation library for Windows
called Automa: http://www.getautoma.com. We want to add some features to our library but
are unsure how to best expose them via our API. It would be extremely helpful for us if
you could let us know which API design feels "right" to you.
Our API already offers very simple commands for automating the GUI of a Windows
computer. For example:
from automa.api import *
start("Notepad")
write("Hello World!")
press(CTRL + 's')
write("test.txt", into="File name")
click("Save")
click("Close")
When you execute this script, Automa starts Notepad and simulates key strokes,
mouse movements and clicks to perform the required commands. At the moment,
each action is performed in the currently active window.
We do not (yet) have a functionality that allows you to explicitly switch to a
specific window. Such a functionality would for instance make it possible to
open two Notepad windows using the start(...) command, and copy text between
them.
One API design would be to have our start(...) function return a "Window" (say)
object, whose methods allow you to do the same operations as the global functions
write(...), press(...), click(...) etc., but in the respective window. In this design,
the example of operating two Notepad windows could be written as
notepad_1 = start("Notepad")
notepad_2 = start("Notepad")
notepad_1.write("Hello World!")
notepad_1.press(CTRL + 'a', CTRL + 'c')
notepad_2.press(CTRL + 'v')
This is the way to go. Just move your global functions into the Window object (or whatever you call it), break
backwards compatibility (major version number change, perhaps?), and call it good.
It makes much more sense to call methods of several different objects (which is explicit -- you always know which object
is being used) than having a magic function that changes the object in the background (plus you now have to search
backwards for the last magic invocation to know -- and what if a called function changes it?).
--
~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list
Re: Performance of int/long in Python 3
On 03/25/2013 02:51 PM, Chris Angelico wrote: Python 3's int is faster than Python 2's long, but slower than Python 2's int. So the question really is, would a two-form representation be beneficial, and if so, is it worth the coding trouble? I'm inclined to say it's not worth the trouble. If you're working with numbers, and speed is an issue, you really should be using one of the numeric or scientific packages out there. -- ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Performance of int/long in Python 3
On Mon, Mar 25, 2013 at 4:35 PM, Cousin Stanley wrote: > > Chris Angelico wrote: > > > The Python 3 merge of int and long has effectively penalized > > small-number arithmetic by removing an optimization. > > > > The cost is clear. > > > I thought I heard that Python 3.x will use machine words for small integers, and automatically coerce internally to a 2.x long as needed. Either way, it's better to have a small performance cost to avoid problems when computers move from 32 to 64 bit words, or 64 bit to 128 bit words. With 3.x int's, you don't have to worry about a new crop of CPU's breaking your code. -- http://mail.python.org/mailman/listinfo/python-list
Re: Performance of int/long in Python 3
Chris Angelico wrote: > The Python 3 merge of int and long has effectively penalized > small-number arithmetic by removing an optimization. > > The cost is clear. > The cost isn't quite as clear under Debian Wheezy here Stanley C. Kitching Debian Wheezy python inline range_sum forloop forloop_offset 2.7.3 3.1359 3.0725 9.0778 15.6475 3.2.3 2.8226 2.807413.47624 13.6430 # - Chris Angelico Debian Wheezy python inline range_sum forloop forloop_offset 2.7.3 1.9276 1.9341 5.1463 5.1346 3.2.3 2.8841 2.6586 7.6602 8.1182 -- Stanley C. Kitching Human Being Phoenix, Arizona -- http://mail.python.org/mailman/listinfo/python-list
Re: Help me pick an API design (OO vs functional)
On 03/25/2013 03:29 PM, Michael Herrmann wrote:
Hello everyone,
my name is Michael, I'm the lead developer of a Python GUI automation library for Windows
called Automa: http://www.getautoma.com. We want to add some features to our library but
are unsure how to best expose them via our API. It would be extremely helpful for us if
you could let us know which API design feels "right" to you.
Our API already offers very simple commands for automating the GUI of a Windows
computer. For example:
from automa.api import *
start("Notepad")
write("Hello World!")
press(CTRL + 's')
write("test.txt", into="File name")
click("Save")
click("Close")
When you execute this script, Automa starts Notepad and simulates key strokes,
mouse movements and clicks to perform the required commands. At the moment,
each action is performed in the currently active window.
We do not (yet) have a functionality that allows you to explicitly switch to a
specific window. Such a functionality would for instance make it possible to
open two Notepad windows using the start(...) command, and copy text between
them.
One API design would be to have our start(...) function return a "Window" (say)
object, whose methods allow you to do the same operations as the global functions
write(...), press(...), click(...) etc., but in the respective window. In this design,
the example of operating two Notepad windows could be written as
notepad_1 = start("Notepad")
notepad_2 = start("Notepad")
notepad_1.write("Hello World!")
notepad_1.press(CTRL + 'a', CTRL + 'c')
notepad_2.press(CTRL + 'v')
The problem with this design is that it effectively duplicates our API: We want to keep our
"global" functions because they are so easy to read. If we add methods to a new "Window"
class that do more or less the same, we feel that we are violating Python's principle that "There should
be one - and preferably only one - obvious way to do it."
An alternative design would be to make the window switching an explicit action. One way of doing
this would be to add a new global function, say "switch_to" or "activate", that
takes a single parameter that identifies the window to be switched to. We could still have
start(...) return a Window object, that could then be passed to our function:
notepad_1 = start("Notepad")
notepad_2 = start("Notepad")
switch_to(notepad_1)
write("Hello World!")
press(CTRL + 'a', CTRL + 'c')
switch_to(notepad_2)
press(CTRL + 'v')
Maybe our Window objects could also be used as context managers:
notepad_1 = start("Notepad")
notepad_2 = start("Notepad")
with notepad_1:
write("Hello World!")
press(CTRL + 'a', CTRL + 'c')
with notepad_2:
press(CTRL + 'v')
As a final idea, switching could also be done as a method of the Window class:
notepad_1 = start("Notepad")
notepad_2 = start("Notepad")
notepad_1.activate()
write("Hello World!")
press(CTRL + 'a', CTRL + 'c')
notepad_2.activate()
press(CTRL + 'v')
It would be extremely helpful for us if you could let me know which way of using the API you would prefer. If
you opt for an explicit version, how would you call the respective method? "activate" /
"switch_to" / "focus" or something else?
Thank you so much!
Best wishes,
Michael
I think I would prefer context managers. I don't think it's a big
problem for
win users because this behaviour would be one of the first things documented
in the start guide and would be all over example scripts, so a new user
missing
or forgetting it is not a realistic scenario.
The advantages are that it's explicit, blocks are indented and it's
impossible to
miss which window is the action applied to, and at the same time actions are
short and easy to type and read.
-m
--
Lark's Tongue Guide to Python: http://lightbird.net/larks/
--
http://mail.python.org/mailman/listinfo/python-list
Re: Performance of int/long in Python 3
On Mon, 25 Mar 2013 16:16:05 -0700, Ethan Furman wrote: > On 03/25/2013 02:51 PM, Chris Angelico wrote: >> Python 3's int is faster than Python 2's long, but slower than Python >> 2's int. So the question really is, would a two-form representation be >> beneficial, and if so, is it worth the coding trouble? > > I'm inclined to say it's not worth the trouble. If you're working with > numbers, and speed is an issue, you really should be using one of the > numeric or scientific packages out there. Or PyPy, which will probably optimize it just fine. Also, speaking as somebody who remembers a time when ints where not automatically promoted to longs (introduced in, Python 2.2, I think?) let me say that having a single unified int type is *fantastic*, and managing ints/longs by hand is a right royal PITA. What I would like to see though is a module where I can import fixed- width signed and unsigned integers that behave like in C, complete with overflow, for writing code that matches the same behaviour as other languages. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Performance of int/long in Python 3
On Tue, Mar 26, 2013 at 11:17 AM, Steven D'Aprano wrote: > Also, speaking as somebody who remembers a time when ints where not > automatically promoted to longs (introduced in, Python 2.2, I think?) let > me say that having a single unified int type is *fantastic*, and managing > ints/longs by hand is a right royal PITA. Oh, I absolutely agree! I'm just looking at performance here, but definitely the int/long unification is a Good Thing. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Performance of int/long in Python 3
On 26 March 2013 00:17, Steven D'Aprano wrote: > On Mon, 25 Mar 2013 16:16:05 -0700, Ethan Furman wrote: > [snip] >> If you're working with >> numbers, and speed is an issue, you really should be using one of the >> numeric or scientific packages out there. > [snip] > What I would like to see though is a module where I can import fixed- > width signed and unsigned integers that behave like in C, complete with > overflow, for writing code that matches the same behaviour as other > languages. Numpy can do this: >>> import numpy >>> a = numpy.array([0], numpy.uint32) >>> a array([0], dtype=uint32) >>> a[0] = -1 >>> a array([4294967295], dtype=uint32) Unfortunately it doesn't work with numpy "scalars", so to use this without the index syntax you'd need a wrapper class. Also it uses Python style floor rounding rather than truncation as in C (actually I seem to remember discovering that in C this is implementation defined). Presumably ctypes has something like this as well. Oscar -- http://mail.python.org/mailman/listinfo/python-list
Re: Performance of int/long in Python 3
In article <5150e900$0$29998$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano wrote: > Also, speaking as somebody who remembers a time when ints where not > automatically promoted to longs (introduced in, Python 2.2, I think?) let > me say that having a single unified int type is *fantastic*, And incredibly useful when solving Project Euler problems :-) [I remember when strings didn't have methods] -- http://mail.python.org/mailman/listinfo/python-list
Re: Separate Rows in reader
On Monday, March 25, 2013 11:51:51 PM UTC+10, rusi wrote:
> On Mar 25, 11:52 am, Jiewei Huang wrote:
>
> > On Sunday, March 24, 2013 9:10:45 PM UTC+10, ypsun wrote:
>
> > > Jiewei Huang於 2013年3月24日星期日UTC+1上午6時20分29秒寫道：
>
> >
>
> > > > Hi all,
>
> >
>
> > > > Currently create a simple text-based database of information about
> > > > people
>
> >
>
> > > > I have a csv file which consist of 3 rows , row 1 2 and 3 is as such:
>
> >
>
> > > > Name Address Telephone Birthday
>
> >
>
> > > > John Konon Ministry of Moon Walks 4567882 27-Feb
>
> >
>
> > > > Stacy Kisha Ministry of Man Power 1234567 17-Jan
>
> >
>
> > > > My codes are :
>
> >
>
> > > > import csv
>
> >
>
> > > > original = file('friends.csv', 'rU')
>
> >
>
> > > > reader = csv.reader(original)
>
> >
>
> > > > for row in reader:
>
> >
>
> > > > print row
>
> >
>
> > > > and the output is :
>
> >
>
> > > > ['Name', ' Address', 'Telephone', 'Birthday']
>
> >
>
> > > > ['John Konon', 'Ministry of Moon Walks', '4567882', '27-Feb']
>
> >
>
> > > > ['Stacy Kisha', 'Ministry of Man Power', '1234567', '17-Jan']
>
> >
>
> > > > But i wanted to make it
>
> >
>
> > > > [('John Cleese', 'Ministry of Silly Walks', '421', '27-Feb'),
>
> >
>
> > > > ( 'Stacy Kisha', 'Ministry of Man Power', '1234567', 17-Jan')]
>
> >
>
> > > > can someone show me guidance to this issue
>
> >
>
> > > > Thanks all
>
> >
>
> > > import csv
>
> >
>
> > > original = file('friends.csv', 'rU')
>
> >
>
> > > reader = csv.reader(original)
>
> >
>
> > > print [tuple(row) for row in reader][1:]
>
> >
>
> > > is this you want?
>
> >
>
> > > Note that:
>
> >
>
> > > 1) I assume your csv file content are seperated by comma
>
> >
>
> > > 2) this way allocates your memory, will be a trouble when a big table
> > > :P
>
> >
>
> > Hi guys, i got into another situation i was told not to use csv library and
> > currently my code is :
>
> >
>
> > f = open('friends.csv', 'rU')
>
> > for row in f:
>
> >
>
> > print [row for (row) in f]
>
> >
>
> > output :
>
> > ['John Cleese,Ministry of Silly Walks,421,27-Oct\n', 'Stacy
> > Kisha,Ministry of Man Power,1234567,17-Jan\n']
>
> >
>
> > i need it to become :
>
> > [('John Cleese', 'Ministry of Silly Walks', '421', '27-Oct'), ('Stacy
> > Kisha', 'Ministry of Man Power', '1234567', '17-Jan')]
>
> >
>
> > guide me please
>
>
>
> Have you tried the split (and perhaps strip) methods from
>
> http://docs.python.org/2/library/stdtypes.html#string-methods
>
> ?
can show me one line of how to implement it base on my problem?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Separate Rows in reader
On 03/25/2013 09:05 PM, Jiewei Huang wrote:
> On Monday, March 25, 2013 11:51:51 PM UTC+10, rusi wrote:
If you insist on using GoogleGroups, then make sure you keep your quotes
small. I'm about to stop reading messages that are double-spaced by
buggy software.
Have you tried the split (and perhaps strip) methods from
http://docs.python.org/2/library/stdtypes.html#string-methods
?
You got lots of specific advice from your previous thread. So which
version did you end up using? It'd make a good starting place for this
"problem."
can show me one line of how to implement it base on my problem?
As long as the input data is constrained not to have any embedded
commas, just use:
mylist = line.split(",")
instead of print, send your output to a list. Then for each line in the
list, fix the bracket problem to your strange specs.
outline = outline.replace("[", "(")
--
--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
Re: io.BytesIO
Hi Steve, thanks for your reply. Actually I played around with these methods. Whe you truncate(12468) for example, I thought the object would allocate 12468 bytes and I wanted to get that back. The methods your mention, works only for what ha been written (obj.write()). I think I should use io.BufferedWriter instead. Just one question, what has better performance: BufferedWriter or BytesIO? Thanks and regards, Fabian On 03/25/2013 01:54 AM, Steven D'Aprano wrote: > On Mon, 25 Mar 2013 00:10:04 -0500, Fabian von Romberg wrote: > >> Hi Steven, >> >> >> actually why I need is to know how much memory has been allocated for >> buffering. >> >> getsizeof gets the size of the object structure. > > I can see at least four ways to get the current size of the BytesIO > buffer: > > py> obj = io.BytesIO(b"x"*12468) > py> obj.getbuffer().nbytes > 12468 > py> len(obj.getvalue()) > 12468 > py> len(obj.getbuffer()) > 12468 > py> obj.seek(0, 2) > 12468 > > > As far as I can tell, BytesIO objects do not have a fixed size buffer. > They will increase in size as needed, just like real file objects on a > disk. > > > -- http://mail.python.org/mailman/listinfo/python-list
Re: Separate Rows in reader
On Tuesday, March 26, 2013 11:40:51 AM UTC+10, Dave Angel wrote:
> On 03/25/2013 09:05 PM, Jiewei Huang wrote:
>
> > On Monday, March 25, 2013 11:51:51 PM UTC+10, rusi wrote:
>
>
>
> If you insist on using GoogleGroups, then make sure you keep your quotes
>
> small. I'm about to stop reading messages that are double-spaced by
>
> buggy software.
>
>
>
> >>>
>
> >>
>
>
>
> >>
>
> >>
>
> >> Have you tried the split (and perhaps strip) methods from
>
> >>
>
> >> http://docs.python.org/2/library/stdtypes.html#string-methods
>
> >>
>
> >> ?
>
>
>
> You got lots of specific advice from your previous thread. So which
>
> version did you end up using? It'd make a good starting place for this
>
> "problem."
>
>
>
>
>
>
>
> > can show me one line of how to implement it base on my problem?
>
> >
>
>
>
> As long as the input data is constrained not to have any embedded
>
> commas, just use:
>
>
>
> mylist = line.split(",")
>
>
>
>
>
> instead of print, send your output to a list. Then for each line in the
>
> list, fix the bracket problem to your strange specs.
>
>
>
> outline = outline.replace("[", "(")
>
>
>
> --
>
> --
>
> DaveA
Hi Dave thanks for the tips,
I manage to code this:
f = open('Book1.csv', 'rU')
for row in f:
print zip([row for (row) in f])
however my output is
[('John Konon Ministry of Moon Walks 4567882 27-Feb\n',), ('Stacy Kisha
Ministry of Man Power 1234567 17-Jan\n',)]
is there any method to remove the \n ?
--
http://mail.python.org/mailman/listinfo/python-list
Re: import in Python3.3
On Sunday, March 24, 2013 8:27:56 PM UTC-4, Steven D'Aprano wrote: > On Sun, 24 Mar 2013 18:12:49 -0500, Fabian von Romberg wrote: > > > > > Hi, > > > > > > I have a package name collections and inside of my package I want to > > > import the collections package from the standard library, but there is > > > name conflicts. > > > > > > How do I import explicitly from the standard library? > > > > You can't. However, you can import explicitly from your package, or > > implicitly by using a relative import. > > > > Starting from Python 2.7, the "import" statement is always absolute. So > > the line: > > > > import collections > > > > will always find the first *top level* module or package "collections" in > > the python search path. See below for an important proviso. > > > > Inside your package, you can either use an explicit import like this: > > > > import mypackage.collections as collections > > > > or use a relative import like this: > > > > from . import collections > > > > Here is a concrete example. I create a package containing five files: > > > > mypackage/ > > +-- __init__.py > > +-- collections.py > > +-- absolute_import.py > > +-- explicit_import.py > > +-- relative_import.py > > > > with the following content: > > > > # absolute_import.py > > import collections > > > > # explicit_import.py > > import mypackage.collections as collections > > > > # relative_import.py > > from . import collections > > > > > > The other two files (collections.py and __init__.py) can be blank. Now, > > from *outside* the package, I can do this: > > > > > > py> import mypackage.absolute_import > > py> import mypackage.explicit_import > > py> import mypackage.relative_import > > py> > > py> mypackage.absolute_import.collections > > > > py> mypackage.explicit_import.collections > > > > py> mypackage.relative_import.collections > > > > > > > > Of course "from mypackage import absolute_import" etc. will also work. > > > > > > However, beware: if you cd into the package directory, and then launch > > Python, the current directory will contain a file "collections.py" which > > will shadow the standard library collections.py. So don't do that. I find this kind of thing sad: it feels to me that programmers are working around somewhat arbitrary and changing restrictions. Rather than avoid names like "collections", why not try to address the underlying problem? There isn't an ambiguity here in my view: the fullname is mypackage.collections It was for this reason I wrote import_relative http://code.google.com/p/pyimport-relative/. It is far from perfect, but it pleases me to think that I one can adjust the language to do reasonable things rather than having it bend me into figuring out what's out there and limit the choice of names I use in submodules. > > > > > > > > -- > > Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Separate Rows in reader
On 26/03/2013 03:33, Jiewei Huang wrote:
On Tuesday, March 26, 2013 11:40:51 AM UTC+10, Dave Angel wrote:
On 03/25/2013 09:05 PM, Jiewei Huang wrote:
On Monday, March 25, 2013 11:51:51 PM UTC+10, rusi wrote:
If you insist on using GoogleGroups, then make sure you keep your quotes
small. I'm about to stop reading messages that are double-spaced by
buggy software.
>>>
>> Have you tried the split (and perhaps strip) methods from
>>
>> http://docs.python.org/2/library/stdtypes.html#string-methods
>>
>> ?
You got lots of specific advice from your previous thread. So which
version did you end up using? It'd make a good starting place for this
"problem."
> can show me one line of how to implement it base on my problem?
>
As long as the input data is constrained not to have any embedded
commas, just use:
mylist = line.split(",")
instead of print, send your output to a list. Then for each line in the
list, fix the bracket problem to your strange specs.
outline = outline.replace("[", "(")
Hi Dave thanks for the tips,
I manage to code this:
f = open('Book1.csv', 'rU')
for row in f:
print zip([row for (row) in f])
however my output is
[('John Konon Ministry of Moon Walks 4567882 27-Feb\n',), ('Stacy Kisha
Ministry of Man Power 1234567 17-Jan\n',)]
is there any method to remove the \n ?
Use the .rstrip method:
print zip(row.rstrip('\n') for row in f)
--
http://mail.python.org/mailman/listinfo/python-list
python3 string format
HI.
one thing confuses me.
It is said in the pep3101 that "{}".format (x) will invoke the method
x.__format__
However, I looked at the src of python3 and found:
in class str(object), the format simply contains a pass statement
in class int(object), things is the same.
So, what's the mechanism that "{}" works?
Thx
--
My gpg pubring is available via: gpg --keyserver
subkeys.pgp.net--recv-keys 307CF736
More on: http://about.me/introom
--
http://mail.python.org/mailman/listinfo/python-list
Re: Performance of int/long in Python 3
On Mon, 25 Mar 2013 20:55:03 -0400, Roy Smith wrote: > In article <5150e900$0$29998$c3e8da3$54964...@news.astraweb.com>, > Steven D'Aprano wrote: > >> Also, speaking as somebody who remembers a time when ints where not >> automatically promoted to longs (introduced in, Python 2.2, I think?) >> let me say that having a single unified int type is *fantastic*, > > And incredibly useful when solving Project Euler problems :-) > > [I remember when strings didn't have methods] No string methods? You were lucky. When I were a lad, you couldn't even use "" delimiters for strings. >>> "b string" Parsing error: file , line 1: "b string" ^ Unhandled exception: run-time error: syntax error Python 0.9.1. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Performance of int/long in Python 3
On Tue, Mar 26, 2013 at 4:01 PM, Steven D'Aprano > No string methods? You were lucky. When I were a lad, you couldn't even > use "" delimiters for strings. > "b string" > Parsing error: file , line 1: > "b string" > ^ > Unhandled exception: run-time error: syntax error > > > Python 0.9.1. Well of course that's an error. Anyone can see it should have been: >>> "a string" *duck* ChrisA -- http://mail.python.org/mailman/listinfo/python-list
At a loss on python scoping.
Hi, suppose I have a file like this: class A: r = 5 def func(self, s): self.s = s a = A() print(a.r)# this should print 5, but where does py store the name of r a.func(3) print(a.s)# this should print 3, also where does py store this name. what's the underlying difference between the above example? -- My gpg pubring is available via: gpg --keyserver subkeys.pgp.net--recv-keys 307CF736 More on: http://about.me/introom -- http://mail.python.org/mailman/listinfo/python-list
Re: python3 string format
On Mon, Mar 25, 2013 at 10:24 PM, Shiyao Ma wrote:
> HI.
> one thing confuses me.
> It is said in the pep3101 that "{}".format (x) will invoke the method
> x.__format__
> However, I looked at the src of python3 and found:
> in class str(object), the format simply contains a pass statement
> in class int(object), things is the same.
I don't know what source you're looking at. In CPython, both of those
types are implemented in C, not Python, so there would be no pass
statements involved.
The int.__format__ method is implemented at:
http://hg.python.org/cpython/file/3c437e591499/Objects/longobject.c#l4373
It mainly just calls the _PyLong_FormatAdvancedWriter function, which is at:
http://hg.python.org/cpython/file/3c437e591499/Python/formatter_unicode.c#l1399
The str.__format__ method similarly is implemented at:
http://hg.python.org/cpython/file/3c437e591499/Objects/unicodeobject.c#l12851
and calls the _PyUnicode_FormatAdvancedWriter function at:
http://hg.python.org/cpython/file/3c437e591499/Python/formatter_unicode.c#l1363
--
http://mail.python.org/mailman/listinfo/python-list
Re: At a loss on python scoping.
PS, I now python's scoping rule is lexical rule (aka static rule). How does LEGB apply to class? On Tue, Mar 26, 2013 at 2:17 PM, Shiyao Ma wrote: > Hi, > suppose I have a file like this: > class A: > r = 5 > def func(self, s): > self.s = s > a = A() > print(a.r)# this should print 5, but where does py store the name of r > > a.func(3) > print(a.s)# this should print 3, also where does py store this name. > what's the underlying difference between the above example? > > > -- > My gpg pubring is available via: gpg --keyserver subkeys.pgp.net--recv-keys > 307CF736 > > More on: http://about.me/introom > > -- My gpg pubring is available via: gpg --keyserver subkeys.pgp.net--recv-keys 307CF736 More on: http://about.me/introom -- http://mail.python.org/mailman/listinfo/python-list
Re: Performance of int/long in Python 3
On Tue, Mar 26, 2013 at 10:35 AM, Cousin Stanley wrote: > > Chris Angelico wrote: > >> The Python 3 merge of int and long has effectively penalized >> small-number arithmetic by removing an optimization. >> >> The cost is clear. >> > > The cost isn't quite as clear > under Debian Wheezy here > > Stanley C. Kitching > Debian Wheezy > > python inline range_sum forloop forloop_offset > > 2.7.3 3.1359 3.0725 9.0778 15.6475 > > 3.2.3 2.8226 2.807413.47624 13.6430 Interesting, so your 3.x sum() is optimizing something somewhere. Strange. Are we both running the same Python? I got those from apt-get, aiming for consistency (rather than building a 3.3 from source). The cost is still visible in the for-loop versions, though, and you're still seeing the <2^31 and >2^31 for-loops behave the same way in 3.x but perform quite differently in 2.x. So it's looking like things are mostly the same. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: At a loss on python scoping.
On Tue, Mar 26, 2013 at 5:17 PM, Shiyao Ma wrote: > class A: > r = 5 > def func(self, s): > self.s = s > a = A() > print(a.r)# this should print 5, but where does py store the name of r What do you mean by "the name of r"? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.2.4 rc 1 and Python 3.3.1 rc 1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On behalf of the Python development team, I am pleased to announce the first release candidates of Python 3.2.4 and 3.3.1. Python 3.2.4 will be the last regular maintenance release for the Python 3.2 series, while Python 3.3.1 is the first maintenance release for the 3.3 series. Both releases include hundreds of bugfixes. There has recently been a lot of discussion about XML-based denial of service attacks. Specifically, certain XML files can cause XML parsers, including ones in the Python stdlib, to consume gigabytes of RAM and swamp the CPU. These releases do not include any changes in Python XML code to address these issues. Interested parties should examine the defusedxml package on PyPI: https://pypi.python.org/pypi/defusedxml These are testing releases: Please consider trying them with your code and reporting any bugs you may notice to: http://bugs.python.org/ To download Python 3.2.4 or Python 3.3.1, visit: http://www.python.org/download/releases/3.2.4/ or http://www.python.org/download/releases/3.3.1/ respectively. Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and all contributors) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlFRRIoACgkQN9GcIYhpnLD6jACgnzYdYRKZ4kwkKeN3zSLSZ3Zr M/IAn17vlpxI3a3xk+i/ODOrCkMnRZro =B5sA -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
