Re: Missing library path (WIndows)

[Kwpolska]

On Sat, Sep 29, 2012 at 4:39 AM, FPEFPE  wrote:
> Hello -- I am running python from an application, starting it with a call to 
> the python31.dll
>
> I think I am missing something in my path -- any help would be appreciated -- 
> thanks

Nope, you are not.

> File "C:\Python32\Lib\encodings\cp437.py", line 19, in encode
>
> return codecs.charmap_encode(input,self.errors,encoding_map)[0]
>
> UnicodeEncodeError: 'charmap' codec can't encode characters in position 2-18: 
> character maps to
> --
> http://mail.python.org/mailman/listinfo/python-list

Python has problems with encoding the arguments to look properly with
the crappy Windows cmd.exe encodings. They cannot be encoded for some
reason.  You may need magic, but I’m not quite sure what in Py3k
(bytestrings?)

-- 
Kwpolska 
stop html mail  | always bottom-post
www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
GPG KEY: 5EAAEA16
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to pass FILE *

[xDog Walker]

On Friday 2012 September 28 21:27, you wrote:
> A tiny bit of googling suggests the following approach:
> http://stackoverflow.com/questions/3794309/python-ctypes-python-file-object
>-c-file/3794401#3794401

Thanks for your response. 

My "tiny bit of Googling" brought no joy but I did try successfully the same 
method suggested by Alex Martelli: use libc's fdopen to get a FILE * for 
ctypes. I would have posted a reply to my own post but it didn't show up.

-- 
Yonder nor sorghum stenches shut ladle gulls stopper torque wet 
strainers.

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

RE: Fastest web framework

[Andriy Kornatskyy]

Tarek,

My response inline to your:

> You are not getting my point. What happens to weezhy or XXX framework
> when you are running it in a given stack, under heavy load ?

let me correct you, it is wheezy.web (not `weezhy`).

Tell me your definition of web framework heavy load. If you have one, we
can try benchmark it.

> There are many interactions that may impact the behavior of the stack -
> most of them are in the web server itself, but they can be things in the
> framework too, depending on the architectural choice.

The reason I choose uWSGI is due to minimal possible impact that application
server may cause. Since this component `equally influence` productivity
of each framework it can be to some degree ignored.

> And you will not know it with an hello world app. To put it more
> bluntly, your benchmark is going to join the big pile of hello worlds
> benchmarks that are completely meaningless.

Can not agree. This is just simple thing. Simple things should run
fast, no doubt. If you can provide a better idea as to which framework
calls to put into benchmark, I will be happy extend the benchmark case.

> If you want to prove that weezhy is faster than another py framework,
> because, I dunno, the number of function calls are smaller ? then you
> need to isolate this and
> do a different kind of bench.
>
> Have a look at http://plope.com/pyroptimization , it's a good example

The numbers provided in that article are incorrect. They didn't match results
from the file they provide (result.txt in each framework dir) at the time 
of writing.

I have used that idea to re-run things (isolated benchmark; report with 
total time, total number of calls and number of distinct functions used).
See here:

https://bitbucket.org/akorn/helloworld/src/tip/benchmark.py

I will update original post a bit later (to let you comment on this).

> Same thing for the raw speed of your templating engine - isolation is
> required.

Improved bigtable benchmark report by adding total number of calls and
number distinct functions used:
https://bitbucket.org/akorn/wheezy.template/src/tip/demos/bigtable/bigtable.py

Original post not updated yet.

> One good read:
> http://blog.ianbicking.org/2010/03/16/web-server-benchmarking-we-need/

Sounds not so bad. It points to some specific workloads. Any attempt to 
prioritize
and/or practically implement them?

Thanks.

Andriy



> Date: Wed, 26 Sep 2012 11:41:26 +0200
> From: ta...@ziade.org
> To: andriy.kornats...@live.com
> CC: python-list@python.org
> Subject: Re: Fastest web framework
>
> On 9/26/12 11:26 AM, Andriy Kornatskyy wrote:
> > Tarek,
> >
> > Thank you for the response back. Yes, your idea is pretty clear to me. The 
> > point is that higher workload you put in your application business logic, 
> > repository, backend, whatever... less you will see in final results 
> > comparison. This is obvious and we, as technical people, very well 
> > understand this (somebody even laugh).
>
> I am happy somebody got a good laugh, I had a myself a good coffee :)
>
> > The reality is that not all web applications do heavy CPU computations 
> > and/or experience IO delays (due to response from database running a query 
> > over table that has no index, let say), some use caches, some split jobs to 
> > be run in background, some parallel them... I have to state that simple 
> > things must perform really fast to give more room for one that are not so. 
> > That in turn makes your infrastructure more effective. Some prefer to add a 
> > box, some see that a likely to be a problem further it goes. The good thing 
> > - you have a choice, you are not locked, and as result you are responsible 
> > for the effectiveness of the system you build today and definitely next one.
> >
> > Take care.
> >
> > Andriy
>
> You are not getting my point. What happens to weezhy or XXX framework
> when you are running it in a given stack, under heavy load ?
>
> There are many interactions that may impact the behavior of the stack -
> most of them are in the web server itself, but they can be things in the
> framework too, depending on the architectural choice.
>
> And you will not know it with an hello world app. To put it more
> bluntly, your benchmark is going to join the big pile of hello worlds
> benchmarks that are completely meaningless.
>
> If you want to prove that weezhy is faster than another py framework,
> because, I dunno, the number of function calls are smaller ? then you
> need to isolate this and
> do a different kind of bench.
>
> Have a look at http://plope.com/pyroptimization , it's a good example
>
> Same thing for the raw speed of your templating engine - isolation is
> required.
>
> One good read:
> http://blog.ianbicking.org/2010/03/16/web-server-benchmarking-we-need/
>
>
> Cheers
> Tarek
>
> >
> >
> > 
> >> Date: Wed, 26 Sep 2012 11:08:19 +0200
> >> From: ta...@ziade.org
> >> To: andriy.kornats...@liv

Re: How to pass FILE *

[Stefan Behnel]

xDog Walker, 29.09.2012 10:45:
> On Friday 2012 September 28 21:27, you wrote:
>> A tiny bit of googling suggests the following approach:
>> http://stackoverflow.com/questions/3794309/python-ctypes-python-file-object
>> -c-file/3794401#3794401
> 
> Thanks for your response. 
> 
> My "tiny bit of Googling" brought no joy but I did try successfully the same 
> method suggested by Alex Martelli: use libc's fdopen to get a FILE * for 
> ctypes. I would have posted a reply to my own post but it didn't show up.

Given your second post on stackoverflow, you may also consider switching
from ctypes to Cython. It makes these things a bit more straight forward.

Stefan


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

Re: write a regex matches 800-555-1212, 555-1212, and also (800) 555-1212.

[Mark Lawrence]

On 29/09/2012 04:30, Steven D'Aprano wrote:

On Fri, 28 Sep 2012 21:25:35 -0600, Ian Kelly wrote:


Mine is simpler and faster.

r = re.compile("")


The OP doesn't say that you have to compile it, so just:

''

wins.





My understanding is that Python 3.3 has regressed the performance of ''. 
 Surely the Python devs can speed the performance back up and, just for 
us, use less memory at the same time?


--
Cheers.

Mark Lawrence.

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

Re: write a regex matches 800-555-1212, 555-1212, and also (800) 555-1212.

[Chris Angelico]

On Sat, Sep 29, 2012 at 7:38 PM, Mark Lawrence  wrote:
>
> My understanding is that Python 3.3 has regressed the performance of ''.
> Surely the Python devs can speed the performance back up and, just for us,
> use less memory at the same time?

Yes, but to do that we'd have to make Python more Australia-focused
instead of US-centric. As of Python 3.4, the empty string will be
lazily evaluated and be delimited by redback spiders instead of
quotes. That will give a 25% speed and 50% memory usage improvement,
but you'll need to be careful you don't get bitten.

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

Re: write a regex matches 800-555-1212, 555-1212, and also (800) 555-1212.

[Mark Lawrence]

On 29/09/2012 11:05, Chris Angelico wrote:

On Sat, Sep 29, 2012 at 7:38 PM, Mark Lawrence  wrote:


My understanding is that Python 3.3 has regressed the performance of ''.
Surely the Python devs can speed the performance back up and, just for us,
use less memory at the same time?


Yes, but to do that we'd have to make Python more Australia-focused
instead of US-centric. As of Python 3.4, the empty string will be
lazily evaluated and be delimited by redback spiders instead of
quotes. That will give a 25% speed and 50% memory usage improvement,
but you'll need to be careful you don't get bitten.

ChrisA



I'll happily admit that I don't like the way this is going.  Do you 
(plural) think we should take this across to python ideas?


--
Cheers.

Mark Lawrence.

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

Re: how to run shell command like "<

[Kushal Kumaran]

On Sat, Sep 29, 2012 at 6:18 AM, 叶佑群  wrote:
> 于 2012-9-28 16:16, Kushal Kumaran 写道:
>>
>> On Fri, Sep 28, 2012 at 1:15 PM, 叶佑群  wrote:
>>
>>> Hi, all,
>>>
>>>  I have the shell command like this:
>>>
>>> sfdisk -uM /dev/sdb<<  EOT
>>> ,1000,83
>>> ,,83
>>> EOT
>>>
>>>
>>>  I have tried subprocess.Popen, pexpect.spawn and os.popen, but none
>>> of
>>> these works, but when I type this shell command in shell, it is works
>>> fine.
>>> I wonder how to emulate this type of behavior in python , and if someone
>>> can
>>> figure out the reason why?
>>>
>>>  The sample code of subprocess.Popen is:
>>>
>>>  command = ["sfdisk", "-uM",  target, "<>>  ",", 1000, ",", "83", "\r\n",
>>>  ",", ",", "83", "\r\n", "EOT", "\r\n"]
>>>
>>>  pobj = subprocess.Popen (command, bufsize=1, \
>>>  stderr=subprocess.PIPE, stdout=subprocess.PIPE)
>>>
>>>  res = pobj.stderr.readline ()
>>>  if res is not None and pobj.returncode != 0:
>>>  observer.ShowProgress (u"对设备 %s 分区失败！" % target)
>>>  return False
>>>
>> The "<> command.  If you use the communicate method, you can provide input as
>> an argument:
>>
>> command = ["sfdisk", "-uM",  target ]
>> instructions = """
>> ,1000,83
>> ,,83
>> """
>> pobj = subprocess.Popen(command, stdin=subprocess.PIPE,
>> stdout=subprocess.PIPE, stderr=subprocess.PIPE)
>> (output, errors) = pobj.communicate(instructions)
>
> I tried this, but it is still not work.
>

What do you mean by "not work"?

- If you get an exception, copy the entire traceback into an email

- If you do not get an exception, print out the value of the "errors"
variable to see why the command failed.  You can also check
pobj.returncode for the exit status of the subprocess.

A possibility is that you have to replace "sfdisk" with the full path
to the binary, if it cannot be located on the PATH.  So you will
replace it with "/usr/sbin/sfdisk", or "/sbin/sfdisk", or wherever the
file actually is.



> If I want to read the output line by line and not put all output to memory 
> buffer in one
> time, how to write the code?

You can read line by line by calling pobj.stdout.readline() and
pobj.stderr.readline().  You can send input to the process by calling
pobj.stdin.write().  If you manage this interaction "by hand", you
should not call communicate().  Also, you should be aware of the
problem mentioned in the subprocess documentation:

"Use communicate() rather than .stdin.write, .stdout.read or
.stderr.read to avoid deadlocks due to any of the other OS pipe
buffers filling up and blocking the child process."

Is there any reason why you need to read line-by-line?  You could use
communicate(), and then call stdout.splitlines() to get a list of
lines, if that's all you need.

-- 
regards,
kushal
-- 
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.3.0

[Georg Brandl]

On behalf of the Python development team, I'm delighted to announce the
Python 3.3.0 final release.

Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x.  Major new features and changes
in the 3.3 release series are:

* PEP 380, syntax for delegating to a subgenerator ("yield from")
* PEP 393, flexible string representation (doing away with the
   distinction between "wide" and "narrow" Unicode builds)
* A C implementation of the "decimal" module, with up to 120x speedup
   for decimal-heavy applications
* The import system (__import__) now based on importlib by default
* The new "lzma" module with LZMA/XZ support
* PEP 397, a Python launcher for Windows
* PEP 405, virtual environment support in core
* PEP 420, namespace package support
* PEP 3151, reworking the OS and IO exception hierarchy
* PEP 3155, qualified name for classes and functions
* PEP 409, suppressing exception context
* PEP 414, explicit Unicode literals to help with porting
* PEP 418, extended platform-independent clocks in the "time" module
* PEP 412, a new key-sharing dictionary implementation that
   significantly saves memory for object-oriented code
* PEP 362, the function-signature object
* The new "faulthandler" module that helps diagnosing crashes
* The new "unittest.mock" module
* The new "ipaddress" module
* The "sys.implementation" attribute
* A policy framework for the email package, with a provisional (see
   PEP 411) policy that adds much improved unicode support for email
   header parsing
* A "collections.ChainMap" class for linking mappings to a single unit
* Wrappers for many more POSIX functions in the "os" and "signal"
   modules, as well as other useful functions such as "sendfile()"
* Hash randomization, introduced in earlier bugfix releases, is now
   switched on by default

In total, almost 500 API items are new or improved in Python 3.3.
For a more extensive list of changes in 3.3.0, see

 http://docs.python.org/3.3/whatsnew/3.3.html

To download Python 3.3.0 visit:

 http://www.python.org/download/releases/3.3.0/

This is a production release, please report any bugs to

  http://bugs.python.org/


Enjoy!

--
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
--
http://mail.python.org/mailman/listinfo/python-list

Re: [Python-Dev] [RELEASED] Python 3.3.0

[Amit Saha]

On Sat, Sep 29, 2012 at 10:18 PM, Georg Brandl  wrote:
> On behalf of the Python development team, I'm delighted to announce the
> Python 3.3.0 final release.
>
> Python 3.3 includes a range of improvements of the 3.x series, as well
> as easier porting between 2.x and 3.x.  Major new features and changes
> in the 3.3 release series are:
>
> * PEP 380, syntax for delegating to a subgenerator ("yield from")
> * PEP 393, flexible string representation (doing away with the
>distinction between "wide" and "narrow" Unicode builds)
> * A C implementation of the "decimal" module, with up to 120x speedup
>for decimal-heavy applications
> * The import system (__import__) now based on importlib by default
> * The new "lzma" module with LZMA/XZ support
> * PEP 397, a Python launcher for Windows
> * PEP 405, virtual environment support in core
> * PEP 420, namespace package support
> * PEP 3151, reworking the OS and IO exception hierarchy
> * PEP 3155, qualified name for classes and functions
> * PEP 409, suppressing exception context
> * PEP 414, explicit Unicode literals to help with porting
> * PEP 418, extended platform-independent clocks in the "time" module
> * PEP 412, a new key-sharing dictionary implementation that
>significantly saves memory for object-oriented code
> * PEP 362, the function-signature object
> * The new "faulthandler" module that helps diagnosing crashes
> * The new "unittest.mock" module
> * The new "ipaddress" module
> * The "sys.implementation" attribute
> * A policy framework for the email package, with a provisional (see
>PEP 411) policy that adds much improved unicode support for email
>header parsing
> * A "collections.ChainMap" class for linking mappings to a single unit
> * Wrappers for many more POSIX functions in the "os" and "signal"
>modules, as well as other useful functions such as "sendfile()"
> * Hash randomization, introduced in earlier bugfix releases, is now
>switched on by default
>
> In total, almost 500 API items are new or improved in Python 3.3.
> For a more extensive list of changes in 3.3.0, see
>
>  http://docs.python.org/3.3/whatsnew/3.3.html

Redirects to http://docs.python.org/py3k/whatsnew/3.3.html: 404 Not Found.

Cheers,
Amit.

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

Re: Reducing cache/buffer for faster display

[Hans Mulder]

On 29/09/12 02:20:50, Rikishi42 wrote:
> On 2012-09-28, Dennis Lee Bieber  wrote:
>> On Thu, 27 Sep 2012 22:25:39 + (UTC), John Gordon 
>> declaimed the following in gmane.comp.python.general:
>>
>>>
>>> Isn't terminal output line-buffered?  I don't understand why there would
>>> be an output delay.  (Unless the "\r" is messing things up...)
>>
>>  It's the trailing , The \r is being used to reset to the
>> beginning of the console line, but the comma "says" more output for
>> /this/ line will be coming... So no output until explicitly flushed, or
>> a new-line is issued.
> 
> Well, the \r seems to be the problem, allright.
> But output was not completely blocked, just delayed a very long time.  
> 
> So perhaps flushing and a sending a newline aren't the only triggers for
> output.  Perhaps there's a maximum delay or a maximum cumulated size, and
> the output is flushed when such a limit is reached.

There's a maximum cumulated size; it's called the buffer size.
Output goes into a buffer, and when the buffer is full, it's
printed all at once.

One way to avoid it, is to use an unbuffered stream.

Another, more efficient, way to avoid it, is to invoke the
stream's .flush() method after writing to it.

> Anyway, that's mainly academic. I doubt there will be a correction to
> that behaviour. 

It's an optimization.  When it was invented, 40 years ago, it was a
really necessary to do this, to get something resembling performance.

The performance of a system without stream buffering would probably
be tolerable on modern hardware.  But the people maintaining Python
are unlikely to cut out buffering, because few people would benefit
(yours is pretty much the only use case where buffereing hurts) and
some would suffer (those who write many short strings to a disk file).


Hope this helps,

-- HansM

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

Re: [Python-Dev] [RELEASED] Python 3.3.0

[Dave Angel]

On 09/29/2012 08:23 AM, Amit Saha wrote:
> On Sat, Sep 29, 2012 at 10:18 PM, Georg Brandl  wrote:
>> 
>>
>> For a more extensive list of changes in 3.3.0, see
>>
>>  http://docs.python.org/3.3/whatsnew/3.3.html
> Redirects to http://docs.python.org/py3k/whatsnew/3.3.html: 404 Not Found.
>
>
Works for me.  Perhaps a momentary glitch.



-- 

DaveA

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

Re: howto handle nested for

[Hans Mulder]

On 29/09/12 03:15:24, Peter Pearson wrote:
> On Fri, 28 Sep 2012 09:49:36 -0600, Ian Kelly  wrote:
>>
>> levels = 6
>> for combination in itertools.product(xrange(n_syms), levels):
>> # do stuff
> 
 n_syms = 3
 levels = 6
 for combination in itertools.product(xrange(n_syms), levels):
> ...   print combination
> ... 
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: 'int' object is not iterable

>>> n_syms = 3
>>> levels = 6
>>> for combination in itertools.product(xrange(n_syms), repeat=levels):
... print combination
...
(0, 0, 0, 0, 0, 0)
(0, 0, 0, 0, 0, 1)
(0, 0, 0, 0, 0, 2)
(0, 0, 0, 0, 1, 0)
(0, 0, 0, 0, 1, 1)
(0, 0, 0, 0, 1, 2)
(0, 0, 0, 0, 2, 0)
(0, 0, 0, 0, 2, 1)
(0, 0, 0, 0, 2, 2)
(0, 0, 0, 1, 0, 0)

etc.


Hope this helps,

-- HansM



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

Re: [Python-Dev] [RELEASED] Python 3.3.0

[Amit Saha]

On Sat, Sep 29, 2012 at 10:37 PM, Dave Angel  wrote:
> On 09/29/2012 08:23 AM, Amit Saha wrote:
>> On Sat, Sep 29, 2012 at 10:18 PM, Georg Brandl  wrote:
>>> 
>>>
>>> For a more extensive list of changes in 3.3.0, see
>>>
>>>  http://docs.python.org/3.3/whatsnew/3.3.html
>> Redirects to http://docs.python.org/py3k/whatsnew/3.3.html: 404 Not Found.
>>
>>
> Works for me.  Perhaps a momentary glitch.

Yes, I clicked too soon, i guess..

-Amit.
-- 
http://echorand.me
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [Python-Dev] [RELEASED] Python 3.3.0

[Hans Mulder]

On 29/09/12 14:23:49, Amit Saha wrote:
> On Sat, Sep 29, 2012 at 10:18 PM, Georg Brandl  wrote:
>> On behalf of the Python development team, I'm delighted to announce the
>> Python 3.3.0 final release.

Thank you!!!

>> For a more extensive list of changes in 3.3.0, see
>>
>>  http://docs.python.org/3.3/whatsnew/3.3.html
> 
> Redirects to http://docs.python.org/py3k/whatsnew/3.3.html: 404 Not Found.

Somebody has fixed it.

-- HansM




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

Re: [Python-Dev] [RELEASED] Python 3.3.0

[Eli Bendersky]

On Sat, Sep 29, 2012 at 5:18 AM, Georg Brandl  wrote:
> On behalf of the Python development team, I'm delighted to announce the
> Python 3.3.0 final release.
>

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

Re: [Python-Dev] [RELEASED] Python 3.3.0

[Ramchandra Apte]

On Saturday, 29 September 2012 18:55:36 UTC+5:30, eliben  wrote:
> On Sat, Sep 29, 2012 at 5:18 AM, Georg Brandl  wrote:
> 
> > On behalf of the Python development team, I'm delighted to announce the
> 
> > Python 3.3.0 final release.
> 
> >
> 
> 
> 
> Yay :)

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

Re: Should one always add super().__init__() to the __init__?

[Ramchandra Apte]

On Saturday, 29 September 2012 18:57:48 UTC+5:30, Ramchandra Apte  wrote:
> Should one always add super().__init__() to the __init__? The reason for this 
> is the possibility of changing base classes (and forgetting to update the 
> __init__).

This is my first post so I may be breaching nettique.
-- 
http://mail.python.org/mailman/listinfo/python-list

Should one always add super().__init__() to the __init__?

[Ramchandra Apte]

Should one always add super().__init__() to the __init__? The reason for this 
is the possibility of changing base classes (and forgetting to update the 
__init__).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [RELEASED] Python 3.3.0

[Stefan Behnel]

Georg Brandl, 29.09.2012 14:18:
> On behalf of the Python development team, I'm delighted to announce the
> Python 3.3.0 final release.
> [...]
> * PEP 380, syntax for delegating to a subgenerator ("yield from")

Ah, you're so late! Cython has shipped its implementation almost a month
ago! ;)

Stefan


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

Re: [python-list] python application file format

[Ramchandra Apte]

On Saturday, 29 September 2012 02:05:07 UTC+5:30, Prasad, Ramit  wrote:
> Benjamin Jessup wrote:
> 
> > Hello all,
> 
> > 
> 
> > What do people recommend for a file format for a python desktop
> 
> > application? Data is complex with 100s/1000s of class instances, which
> 
> > reference each other.
> 
> > 
> 
> > Write the file with struct module? (Rebuild object pointers, safe,
> 
> > compact, portable, not expandable without reserved space)
> 
> > 
> 
> > Use cPickle with a module/class whitelist? (Can't easily port, not
> 
> > entirely safe, compact enough, expandable)
> 
> > 
> 
> > Use JSON or similar? (Rebuild object pointers, portable, expandable, size?)
> 
> > 
> 
> > Any advice is greatly appreciated!
> 
> 
> 
> I would think your options are pickle, json or database (either sqlite or 
> 
> something like Postgres). I am unfamiliar with the struct module so I 
> 
> cannot comment on its applicability.
> 
> 
> 
> I would guess that your data would be best saved by using a sqlite 
> 
> database. Your biggest problem might be how the different classes are 
> 
> referencing each other. If you are using identifiers then any of these 
> 
> options will probably work. If you are using aggregation then I know
> 
> that pickle will work (at least for built-in types). JSON will
> 
> keep the structure but duplicate elements.
> 
> 
> 
> 
> 
> >>> a = [ 1,2,3 ]
> 
> >>> b = [ 'a', 'b', 'c' ]
> 
> >>> a.append( b )
> 
> >>> e = [ a,b ]
> 
> >>> s = json.dumps( e ) 
> 
> >>> eret = json.loads( s )
> 
> >>> id(eret[0][3]), id(eret[1]) # Same result for json and simplejson
> 
> (329443808, 327677272) 
> 
> >>> eret[0][3].append( 'o')
> 
> >>> eret[0][3], eret[1]
> 
> ([u'a', u'b', u'c', 'o'], [u'a', u'b', u'c'])
> 
> 
> 
> So pickle will be your easiest option, but I am not sure how well it
> 
> will scale with a large number items. Using sqlite/db should scale well
> 
> but it will take you longer/more effort to create a system for converting 
> 
> your objects to and from the DB.
> 
> 
> 
> 
> 
> 
> 
> This email is confidential and subject to important disclaimers and
> 
> conditions including on offers for the purchase or sale of
> 
> securities, accuracy and completeness of information, viruses,
> 
> confidentiality, legal privilege, and legal entity disclaimers,
> 
> available at http://www.jpmorgan.com/pages/disclosures/email.

Guess I shouldn't read or rely your posts (virus'es could be in them) :-D
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: For Counter Variable

[Ramchandra Apte]

On Tuesday, 25 September 2012 05:48:22 UTC+5:30, David Hutto  wrote:
> > Is the animated GIF on your website under 60MB yet?
> 
> yeah a command line called convert, and taking out a few jpegs used to
> 
> convert, and I can reduce it to any size, what's the fucking point of
> 
> that question other than ignorant rhetoric, that you know is easily
> 
> fixable?
> 
> 
> 
> 
> 
> -- 
> 
> Best Regards,
> 
> David Hutto
> 
> CEO: http://www.hitwebdevelopment.com

There are children (such as me) here!
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: [RELEASED] Python 3.3.0

[Andriy Kornatskyy]

The following doctest fails with python3.3 (it is okay for python2.4-2.7, 3.2).

class adict(dict):                                                              
                              
    """                                                                         
                             
        >>> d = adict(a=1, b=2)                                                 
                             
        >>> d                                                                   
                             
        {'a': 1, 'b': 2}                                                        
                              
    """                                                                         
                             
                                                                                
                             
if __name__ == "__main__":                                                      
                              
    import doctest                                                              
                              
    doctest.testmod() 

Please advise if that is something known.

Andriy



> Date: Sat, 29 Sep 2012 14:18:54 +0200
> From: ge...@python.org
> To: python-annou...@python.org; python-...@python.org; python-list@python.org
> Subject: [RELEASED] Python 3.3.0
>
> On behalf of the Python development team, I'm delighted to announce the
> Python 3.3.0 final release.
>
> Python 3.3 includes a range of improvements of the 3.x series, as well
> as easier porting between 2.x and 3.x. Major new features and changes
> in the 3.3 release series are:
>
> * PEP 380, syntax for delegating to a subgenerator ("yield from")
> * PEP 393, flexible string representation (doing away with the
> distinction between "wide" and "narrow" Unicode builds)
> * A C implementation of the "decimal" module, with up to 120x speedup
> for decimal-heavy applications
> * The import system (__import__) now based on importlib by default
> * The new "lzma" module with LZMA/XZ support
> * PEP 397, a Python launcher for Windows
> * PEP 405, virtual environment support in core
> * PEP 420, namespace package support
> * PEP 3151, reworking the OS and IO exception hierarchy
> * PEP 3155, qualified name for classes and functions
> * PEP 409, suppressing exception context
> * PEP 414, explicit Unicode literals to help with porting
> * PEP 418, extended platform-independent clocks in the "time" module
> * PEP 412, a new key-sharing dictionary implementation that
> significantly saves memory for object-oriented code
> * PEP 362, the function-signature object
> * The new "faulthandler" module that helps diagnosing crashes
> * The new "unittest.mock" module
> * The new "ipaddress" module
> * The "sys.implementation" attribute
> * A policy framework for the email package, with a provisional (see
> PEP 411) policy that adds much improved unicode support for email
> header parsing
> * A "collections.ChainMap" class for linking mappings to a single unit
> * Wrappers for many more POSIX functions in the "os" and "signal"
> modules, as well as other useful functions such as "sendfile()"
> * Hash randomization, introduced in earlier bugfix releases, is now
> switched on by default
>
> In total, almost 500 API items are new or improved in Python 3.3.
> For a more extensive list of changes in 3.3.0, see
>
> http://docs.python.org/3.3/whatsnew/3.3.html
>
> To download Python 3.3.0 visit:
>
> http://www.python.org/download/releases/3.3.0/
>
> This is a production release, please report any bugs to
>
> http://bugs.python.org/
>
>
> Enjoy!
>
> --
> Georg Brandl, Release Manager
> georg at python.org
> (on behalf of the entire python-dev team and 3.3's contributors)
> --
> http://mail.python.org/mailman/listinfo/python-list
  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [RELEASED] Python 3.3.0

[Ramchandra Apte]

On Saturday, 29 September 2012 19:08:25 UTC+5:30, Stefan Behnel  wrote:
> Georg Brandl, 29.09.2012 14:18:
> 
> > On behalf of the Python development team, I'm delighted to announce the
> 
> > Python 3.3.0 final release.
> 
> > [...]
> 
> > * PEP 380, syntax for delegating to a subgenerator ("yield from")
> 
> 
> 
> Ah, you're so late! Cython has shipped its implementation almost a month
> 
> ago! ;)
> 
> 
> 
> Stefan

Where did Cython get shipped to?
LOL
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: using "*" to make a list of lists with repeated (and independent) elements

[Ramchandra Apte]

On Thursday, 27 September 2012 04:14:42 UTC+5:30, Tim Chase  wrote:
> On 09/26/12 17:28, 8 Dihedral wrote:
> 
> > 8 Dihedral於 2012年9月27日星期四UTC+8上午6時07分35秒寫道：
> 
>  In these conditions, how to make this list [[0,0,0],[0,0,0]] with "*" 
> 
>  without this behavior?
> 
> >>> >>> a = [[0]*3 for i in xrange(2)]
> 
> >>> >>> a[0][0]=2
> 
> >>> >>> a
> 
> >>> [[2, 0, 0], [0, 0, 0]]
> 
> > 
> 
> > def zeros(m,n):
> 
> > a=[]
> 
> > for i in xrange(m):
> 
> > a.append([0]*n)
> 
> > return a
> 
> > 
> 
> > If  one wants to tranlate to C, this is the style.
> 
> 
> 
> But this is Python, so why the heck would anybody want to emulate
> 
> *C* style?  It could also be written in an assembly-language style,
> 
> COBOL style, or a Fortran style...none of which are particularly
> 
> valuable.
> 
> 
> 
> Besides, a C-style would allocate a single array of M*N slots and
> 
> then calculate 2d offsets into that single array. :-P
> 
> 
> 
> -tkc

8 Dihedral is a bot.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [RELEASED] Python 3.3.0

[Christian Heimes]

Am 29.09.2012 15:42, schrieb Andriy Kornatskyy:
> 
> The following doctest fails with python3.3 (it is okay for python2.4-2.7, 
> 3.2).
> 
> class adict(dict):
> 
> """   
>
> >>> d = adict(a=1, b=2)   
>
> >>> d 
>
> {'a': 1, 'b': 2}  
> 
> """   
>
>   
>
> if __name__ == "__main__":
> 
> import doctest
> 
> doctest.testmod() 
> 
> Please advise if that is something known.

Yes, it's caused by the hash randomization. From now on you can't rely
on the order of an unordered type like dict or set. You could replace d
with sorted(d.items()).

Christian


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

Re: [Python-Dev] [RELEASED] Python 3.3.0

[Paul Moore]

On 29 September 2012 14:24, Eli Bendersky  wrote:
> On Sat, Sep 29, 2012 at 5:18 AM, Georg Brandl  wrote:
>> On behalf of the Python development team, I'm delighted to announce the
>> Python 3.3.0 final release.
>>
>
> Yay :)

Agreed - this is a really nice release, thanks to all who put it together.
Paul
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [RELEASED] Python 3.3.0

[Stefan Behnel]

Christian Heimes, 29.09.2012 16:06:
> From now on you can't rely
> on the order of an unordered type like dict or set.

Tautologies tend to be true even without a temporal qualification.

Stefan


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

Re: [RELEASED] Python 3.3.0

[Chris Angelico]

On Sun, Sep 30, 2012 at 12:17 AM, Stefan Behnel  wrote:
> Christian Heimes, 29.09.2012 16:06:
>> From now on you can't rely
>> on the order of an unordered type like dict or set.
>
> Tautologies tend to be true even without a temporal qualification.

Technically people shouldn't ever have relied on the order, but until
hash randomization came in, the order in CPython was actually
predictable - for a given set of dictionary operations, the internal
structure was determinate, and the consequent iteration order would be
consistent. Now that that's no longer the case, "unordered" really
means "unordered", and the order can change from one run of a program
to another.

So it may be a tautology in theory, but not in practice. until
now. Truth has become true.

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

Re: [Python-Dev] [RELEASED] Python 3.3.0

[python]

> Agreed - this is a really nice release, thanks to all who put it together.

+1

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

Slicing iterables in sub-generators without loosing elements

[Thomas Bach]

Hi,

say we have the following:

>>> data = [('foo', 1), ('foo', 2), ('bar', 3), ('bar', 2)]

is there a way to code a function iter_in_blocks such that

>>> result = [ list(block) for block in iter_in_blocks(data) ]

evaluates to

>>> result = [ [('foo', 1), ('foo', 2)], [('bar', 3), ('bar', 2)] ]

by _only_ _iterating_ over the list (caching all the elements sharing
the same first element doesn't count)?

I came up with the following

def iter_in_blocks(iterable):
my_iter = iter(iterable)
while True:
first = next(my_iter)
pred = lambda entry: entry[0] == first[0]
def block_iter():
yield first
for entry in itertools.takewhile(pred, my_iter):
yield entry
yield block_iter()

which does not work as itertools.takewhile consumes the first entry
not fulfilling the pred.

I currently have the intuition that the problem is not solvable
without using e.g. a global to pass something back to iter_in_blocks
from block_iter. Any other suggestions?

Regards,
Thomas Bach.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Slicing iterables in sub-generators without loosing elements

[Paul Rubin]

Thomas Bach  writes:
 result = [ [('foo', 1), ('foo', 2)], [('bar', 3), ('bar', 2)] ]
> by _only_ _iterating_ over the list (caching all the elements sharing
> the same first element doesn't count)?

itertools.groupby(data, lambda (x,y) : x)

is basically what you want.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: unexpected error from Python 3.3.0

[Dave Angel]

On 09/29/2012 10:19 AM, Alexis Lopez-Garcia wrote:
> Hi.
>
> I installed Python3.3.0 with python-3.3.0.amd64.msi on a win7 machine.
>
> While using this funcion (see below) from a script called by double
> clicking on the .py file I get a "invalid variable "right" referenced
> before assignment" error.

You forgot to include the whole, actual error trace.

> The weird thing is that launching the script from a cmd windows does no
> give the error and if you repeactedly double click on the .py file
> sometimes the error does not reproduce so I concluded it was a timing issue
> between win7 and python.
> So by trial and error I ended up fixing it by inserting a time.sleep(0.5)
> on the function and now it works 100% of the time.
>
> These error did not show in Python3.2.3 and thus I don't know if I just
> found a new bug or what.
> I write it here so that more knowledgeable people could:
>
> 1. explains to me why the errors is happening
see below.
> 2. deems it a bug and maybe reports it on the Python site.

Sure, report it to Microsoft.  For whatever reason, your call to

GetConsoleScreenBufferInfo() is returning false (or something equivalent, like 
0).  What does the Windows 7 documentation say about not attaching a console 
for a while?


> below is the particular function giving the error with the fix line, which
> is not in the original version
>
> def console_resize(width=80, height=24, buffer_height=600):
> '''Sets up the console size and buffer height.
>
> @param width {int} Width of console in column value.
> @param height {int} Height of console in row value.
> @param buffer_height {int} Buffer console height in row value.
> '''
> from ctypes import windll, byref, create_string_buffer
> from ctypes.wintypes import SMALL_RECT, _COORD
> # Active console screen buffer
> # STD_OUTPUT_HANDLE -> -11, STD_ERROR_HANDLE -> -12)
> STDERR = -12
> # SMALL_RECT input
> LEFT = 0
> TOP = 0
> RIGHT = width - 1
> BOTTOM = height - 1
> # handle
> hdl = windll.kernel32.GetStdHandle(STDERR)
> csbi = create_string_buffer(22)
>
> time.sleep(0.5)  # <--- FIX IS THIS LINE
>
> res = windll.kernel32.GetConsoleScreenBufferInfo(hdl, csbi)
>
> if res:
> import struct
> (bufx, bufy, curx, cury, wattr,
>  left, top, right, bottom,
>  maxx, maxy) = struct.unpack("Hhh", csbi.raw)

Your problem is you don't have an else clause.  How did you expect bufs,
bufy, etc. to be initialized without executing that code.  So if the
rest of the function doesn't make sense without a console, you should be
skipping it, or throwing an exception, or returning, or something.



>
> current_width = right - left + 1

This happens to be the first time you tried to use one of those
non-variables.  Naturally, it fails.

> current_height = bottom - top + 1
> current_buffer_height = bufy
>
> if buffer_height < height:
> buffer_height = height
> # order of resizing avoiding some problems
> if current_buffer_height > buffer_height:
> rect = SMALL_RECT(LEFT, TOP, RIGHT, BOTTOM)  # (left, top, right,
> bottom)
> windll.kernel32.SetConsoleWindowInfo(hdl, True, byref(rect))
>
> bufsize = _COORD(width, buffer_height)  # columns, rows
> windll.kernel32.SetConsoleScreenBufferSize(hdl, bufsize)
> else:
> bufsize = _COORD(width, buffer_height)  # columns, rows
> windll.kernel32.SetConsoleScreenBufferSize(hdl, bufsize)
>
> rect = SMALL_RECT(LEFT, TOP, RIGHT, BOTTOM)  # (left, top, right,
> bottom)
> windll.kernel32.SetConsoleWindowInfo(hdl, True, byref(rect))
>
>
>
-- 

DaveA

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

Re: Slicing iterables in sub-generators without loosing elements

[Ian Kelly]

On Sat, Sep 29, 2012 at 10:14 AM, Thomas Bach
 wrote:
> Hi,
>
> say we have the following:
>
 data = [('foo', 1), ('foo', 2), ('bar', 3), ('bar', 2)]
>
> is there a way to code a function iter_in_blocks such that
>
 result = [ list(block) for block in iter_in_blocks(data) ]
>
> evaluates to
>
 result = [ [('foo', 1), ('foo', 2)], [('bar', 3), ('bar', 2)] ]
>
> by _only_ _iterating_ over the list (caching all the elements sharing
> the same first element doesn't count)?

Am I correct in understanding that the intent is that the "blocks" are
groups that share the same first item?

Is it guaranteed that the blocks will be contiguous?  If so, you could
use itertools.groupby:

from itertools import groupby, imap
from operator import itemgetter

def iter_in_blocks(data):
return imap(itemgetter(1), groupby(data, itemgetter(0)))

If there is no such guarantee, then the list would need to be sorted first.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Slicing iterables in sub-generators without loosing elements

[Thomas Bach]

On Sat, Sep 29, 2012 at 09:26:00AM -0700, Paul Rubin wrote:
> Thomas Bach  writes:
> 
> itertools.groupby(data, lambda (x,y) : x)
> 
> is basically what you want.

True!

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

Re: Should one always add super().__init__() to the __init__?

[Ian Kelly]

On Sat, Sep 29, 2012 at 7:27 AM, Ramchandra Apte  wrote:
> Should one always add super().__init__() to the __init__? The reason for this 
> is the possibility of changing base classes (and forgetting to update the 
> __init__).

As long as the class and its subclasses only use single inheritance,
it makes little difference, so if you think it will reduce the
maintenance burden, I would say go for it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: using "*" to make a list of lists with repeated (and independent) elements

[88888 Dihedral]

On Saturday, September 29, 2012 9:46:22 PM UTC+8, Ramchandra Apte wrote:
> On Thursday, 27 September 2012 04:14:42 UTC+5:30, Tim Chase  wrote:
> 
> > On 09/26/12 17:28, 8 Dihedral wrote:
> 
> > 
> 
> > > 8 Dihedral於 2012年9月27日星期四UTC+8上午6時07分35秒寫道：
> 
> > 
> 
> >  In these conditions, how to make this list [[0,0,0],[0,0,0]] with "*" 
> 
> > 
> 
> >  without this behavior?
> 
> > 
> 
> > >>> >>> a = [[0]*3 for i in xrange(2)]
> 
> > 
> 
> > >>> >>> a[0][0]=2
> 
> > 
> 
> > >>> >>> a
> 
> > 
> 
> > >>> [[2, 0, 0], [0, 0, 0]]
> 
> > 
> 
> > > 
> 
> > 
> 
> > > def zeros(m,n):
> 
> > 
> 
> > >   a=[]
> 
> > 
> 
> > >   for i in xrange(m):
> 
> > 
> 
> > >   a.append([0]*n)
> 
> > 
> 
> > >   return a
> 
> > 
> 
> > > 
> 
> > 
> 
> > > If  one wants to tranlate to C, this is the style.
> 
> > 
> 
> > 
> 
> > 
> 
> > But this is Python, so why the heck would anybody want to emulate
> 
> > 
> 
> > *C* style?  It could also be written in an assembly-language style,
> 
> > 
> 
> > COBOL style, or a Fortran style...none of which are particularly
> 
> > 
> 
> > valuable.
> 
> > 
> 
> > 
> 
> > 
> 
> > Besides, a C-style would allocate a single array of M*N slots and
> 
> > 
> 
> > then calculate 2d offsets into that single array. :-P
> 
> > 
> 
> > 
> 
> > 
> 
> > -tkc
> 
> 
> 
> 8 Dihedral is a bot.

Don't you get it why I avoided the lambda one liner as a functon. 

I prefer the def way with a name chosen.

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

Re: write a regex matches 800-555-1212, 555-1212, and also (800) 555-1212.

[Ian Kelly]

On Sat, Sep 29, 2012 at 3:38 AM, Mark Lawrence  wrote:
> My understanding is that Python 3.3 has regressed the performance of ''.
> Surely the Python devs can speed the performance back up and, just for us,
> use less memory at the same time?

At least it will be stored as a Latin-1 '' for efficiency and not a
bloated UCS-4 ''.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to investigate web script not running?

[Ramchandra Apte]

On Friday, 28 September 2012 18:45:41 UTC+5:30, Gilles  wrote:
> On Fri, 28 Sep 2012 14:16:22 +0200, "Michael Ross" 
> 
> wrote:
> 
> >Do it the other way around:
> 
> >
> 
> ># cgitb before anything else
> 
> >import cgitb
> 
> >cgitb.enable()
> 
> >
> 
> ># so this error will be caught
> 
> > from fcgi import WSGIServer
> 
> 
> 
> Thanks much for the tip. The error isn't displayed when calling the
> 
> script from a web browser but it is when running the script on a shell
> 
> account.
> 
> 
> 
> It looks like that newer version of fcgi.py doesn't include support
> 
> for WSGI, and I need some extra (Flup?) software to sit between
> 
> mod_fcgid and a WSGI Python application.
> 
> 
> 
> Definitely not plug 'n play :-/

Well the plug and play standard is superseded by USB practically.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: using "*" to make a list of lists with repeated (and independent) elements

[Ian Kelly]

On Sat, Sep 29, 2012 at 11:01 AM, 8 Dihedral
 wrote:
>
> Don't you get it why I avoided the lambda one liner as a functon.
>
> I prefer the def way with a name chosen.

Certainly, but the Bresenham line algorithm is O(n), which is why it
is so superior to quicksort that is O(n log n).  Of course you might
try the Capo Ferro optimization, but I find that Thibault cancels out
Capo Ferro, don't you?
-- 
http://mail.python.org/mailman/listinfo/python-list

Editing in IDLE

[peterfarrell66]

Hello to the group!

I'm a new Python user and so far I'm enjoying it. One of the many newbie 
problems I'm having is I can't edit my code in IDLE once it's run or there's an 
error message. I can only copy the code so far, paste at the bottom and 
continue coding. Is there something simple I'm missing, or should I be using a 
different editor?

Thanks in advance!

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

Re: Should one always add super().__init__() to the __init__?

[Steven D'Aprano]

On Sat, 29 Sep 2012 06:27:47 -0700, Ramchandra Apte wrote:

> Should one always add super().__init__() to the __init__? The reason for
> this is the possibility of changing base classes (and forgetting to
> update the __init__).

No. Only add code that works and that you need. Arbitrarily adding calls 
to the superclasses "just in case" may not work:



py> class Spam(object):
... def __init__(self, x):
... self.x = x
... super(Spam, self).__init__(x)
...
py> x = Spam(1)
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 4, in __init__
TypeError: object.__init__() takes no parameters



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

Re: using "*" to make a list of lists with repeated (and independent) elements

[Chris Angelico]

On Sun, Sep 30, 2012 at 3:18 AM, Ian Kelly  wrote:
> On Sat, Sep 29, 2012 at 11:01 AM, 8 Dihedral
>  wrote:
>>
>> Don't you get it why I avoided the lambda one liner as a functon.
>>
>> I prefer the def way with a name chosen.
>
> Certainly, but the Bresenham line algorithm is O(n), which is why it
> is so superior to quicksort that is O(n log n).  Of course you might
> try the Capo Ferro optimization, but I find that Thibault cancels out
> Capo Ferro, don't you?

Unless ...

class Agrippa(object):
students = []
def __init__(self):
students.append(self)

enemy = Agrippa()

ChrisA
(maybe I'm pushing this a bit too far)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: unexpected error from Python 3.3.0

[Alexis Lopez-Garcia]

Thanks for pointing me to the right direction.
It seems that GetConsoleScreenBufferInfo() is indeed returning 0 and
further investigation points to the error code 6 (ERROR_INVALID_HANDLE).
No idea why this is so but just doing a while loop until the call gets a
non-zero value seem to work as a fix.

On Sat, Sep 29, 2012 at 6:29 PM, Dave Angel  wrote:

> On 09/29/2012 10:19 AM, Alexis Lopez-Garcia wrote:
> > Hi.
> >
> > I installed Python3.3.0 with python-3.3.0.amd64.msi on a win7 machine.
> >
> > While using this funcion (see below) from a script called by double
> > clicking on the .py file I get a "invalid variable "right" referenced
> > before assignment" error.
>
> You forgot to include the whole, actual error trace.
>
> > The weird thing is that launching the script from a cmd windows does no
> > give the error and if you repeactedly double click on the .py file
> > sometimes the error does not reproduce so I concluded it was a timing
> issue
> > between win7 and python.
> > So by trial and error I ended up fixing it by inserting a time.sleep(0.5)
> > on the function and now it works 100% of the time.
> >
> > These error did not show in Python3.2.3 and thus I don't know if I just
> > found a new bug or what.
> > I write it here so that more knowledgeable people could:
> >
> > 1. explains to me why the errors is happening
> see below.
> > 2. deems it a bug and maybe reports it on the Python site.
>
> Sure, report it to Microsoft.  For whatever reason, your call to
>
> GetConsoleScreenBufferInfo() is returning false (or something equivalent,
> like 0).  What does the Windows 7 documentation say about not attaching a
> console for a while?
>
>
> > below is the particular function giving the error with the fix line,
> which
> > is not in the original version
> >
> > def console_resize(width=80, height=24, buffer_height=600):
> > '''Sets up the console size and buffer height.
> >
> > @param width {int} Width of console in column value.
> > @param height {int} Height of console in row value.
> > @param buffer_height {int} Buffer console height in row value.
> > '''
> > from ctypes import windll, byref, create_string_buffer
> > from ctypes.wintypes import SMALL_RECT, _COORD
> > # Active console screen buffer
> > # STD_OUTPUT_HANDLE -> -11, STD_ERROR_HANDLE -> -12)
> > STDERR = -12
> > # SMALL_RECT input
> > LEFT = 0
> > TOP = 0
> > RIGHT = width - 1
> > BOTTOM = height - 1
> > # handle
> > hdl = windll.kernel32.GetStdHandle(STDERR)
> > csbi = create_string_buffer(22)
> >
> > time.sleep(0.5)  # <--- FIX IS THIS LINE
> >
> > res = windll.kernel32.GetConsoleScreenBufferInfo(hdl, csbi)
> >
> > if res:
> > import struct
> > (bufx, bufy, curx, cury, wattr,
> >  left, top, right, bottom,
> >  maxx, maxy) = struct.unpack("Hhh", csbi.raw)
>
> Your problem is you don't have an else clause.  How did you expect bufs,
> bufy, etc. to be initialized without executing that code.  So if the
> rest of the function doesn't make sense without a console, you should be
> skipping it, or throwing an exception, or returning, or something.
>
>
>
> >
> > current_width = right - left + 1
>
> This happens to be the first time you tried to use one of those
> non-variables.  Naturally, it fails.
>
> > current_height = bottom - top + 1
> > current_buffer_height = bufy
> >
> > if buffer_height < height:
> > buffer_height = height
> > # order of resizing avoiding some problems
> > if current_buffer_height > buffer_height:
> > rect = SMALL_RECT(LEFT, TOP, RIGHT, BOTTOM)  # (left, top, right,
> > bottom)
> > windll.kernel32.SetConsoleWindowInfo(hdl, True, byref(rect))
> >
> > bufsize = _COORD(width, buffer_height)  # columns, rows
> > windll.kernel32.SetConsoleScreenBufferSize(hdl, bufsize)
> > else:
> > bufsize = _COORD(width, buffer_height)  # columns, rows
> > windll.kernel32.SetConsoleScreenBufferSize(hdl, bufsize)
> >
> > rect = SMALL_RECT(LEFT, TOP, RIGHT, BOTTOM)  # (left, top, right,
> > bottom)
> > windll.kernel32.SetConsoleWindowInfo(hdl, True, byref(rect))
> >
> >
> >
> --
>
> DaveA
>
>


-- 
There are more things in heaven and earth, Horatio,
Than are dreamt of in your philosophy.

Alexis Lopez-Garcia
alexis.lopezgar...@gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Editing in IDLE

[Terry Reedy]

On 9/29/2012 1:14 PM, peterfarrel...@gmail.com wrote:

Hello to the group!

I'm a new Python user and so far I'm enjoying it. One of the many
newbie problems I'm having is I can't edit my code in IDLE once it's
run or there's an error message. I can only copy the code so far,
paste at the bottom and continue coding. Is there something simple
I'm missing, or should I be using a different editor?


You are missing how to use IDLE. It has two kinds of windows: 
interactive Shell and Edit windows. The shell more or less emulates the 
interactive interpreter, running one statement at a time. You can put 
the cursor on a previous statement and hit return to make it the current 
statement, where you can edit it. You edit normal multi-statement code 
in edit windows, hit F5 to run, edit, run, edit, run.


--
Terry Jan Reedy

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

Re: Should one always add super().__init__() to the __init__?

[Devin Jeanpierre]

On Sat, Sep 29, 2012 at 1:17 PM, Steven D'Aprano
 wrote:
> No. Only add code that works and that you need. Arbitrarily adding calls
> to the superclasses "just in case" may not work:
>
>
>
> py> class Spam(object):
> ... def __init__(self, x):
> ... self.x = x
> ... super(Spam, self).__init__(x)
> ...
> py> x = Spam(1)
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "", line 4, in __init__
> TypeError: object.__init__() takes no parameters

That's a good thing. We've gone from code that doesn't call the
initializer and leaves the object in a potentially invalid state
(silently!), to code that calls the initializer and then fails
(loudly).

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

Re: Should one always add super().__init__() to the __init__?

[Chris Angelico]

On Sun, Sep 30, 2012 at 3:17 AM, Steven D'Aprano
 wrote:
> No. Only add code that works and that you need. Arbitrarily adding calls
> to the superclasses "just in case" may not work:
>
> py> class Spam(object):
> ... def __init__(self, x):
> ... self.x = x
> ... super(Spam, self).__init__(x)
> ...
> py> x = Spam(1)
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "", line 4, in __init__
> TypeError: object.__init__() takes no parameters

That's because you're subclassing something that doesn't take
parameters and giving it parameters. Of course that won't work. The
normal and logical thing to do is to pass on only the parameters that
you know the parent class expects... but that implies knowing the
parent, so it's kinda moot.

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

Re: Editing in IDLE

[Chris Angelico]

On Sun, Sep 30, 2012 at 3:14 AM,   wrote:
> Hello to the group!
>
> I'm a new Python user and so far I'm enjoying it. One of the many newbie 
> problems I'm having is I can't edit my code in IDLE once it's run or there's 
> an error message. I can only copy the code so far, paste at the bottom and 
> continue coding. Is there something simple I'm missing, or should I be using 
> a different editor?

I only ever use IDLE in its interactive mode (at which, imho, it's
rather better than the default Python interactive mode, as it
auto-indents). In that mode, you can retrieve previous commands with
Alt-P - at least, that's the keystroke on Windows, not sure if it's
different on other platforms.

For editing code that's to be saved in a .py file, I use SciTE, but a
lot of people do use IDLE for that too. It's a matter of personal
preference.

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

Re: using "*" to make a list of lists with repeated (and independent) elements

[88888 Dihedral]

On Sunday, September 30, 2012 1:19:22 AM UTC+8, Ian wrote:
> On Sat, Sep 29, 2012 at 11:01 AM, 8 Dihedral
> 
>  wrote:
> 
> >
> 
> > Don't you get it why I avoided the lambda one liner as a functon.
> 
> >
> 
> > I prefer the def way with a name chosen.
> 
> 
> 
> Certainly, but the Bresenham line algorithm is O(n), which is why it
> 
> is so superior to quicksort that is O(n log n).  Of course you might
> 
> try the Capo Ferro optimization, but I find that Thibault cancels out
> 
> Capo Ferro, don't you?

OK! I'll illustrate the lazy aspect of the python interpreter furthermore.

a=[1,2,3]
b=[a]*4 # different from a sliced copy as [list(a)]*4
print b
a[1]=4
print b
#-
a=666 # type morphed
print b 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: what is the difference between st_ctime and st_mtime one is the time of last change and the other is the time of last modification, but i can not understand what is the difference between 'change'

[Nobody]

On Fri, 28 Sep 2012 11:48:23 -0600, Kristen J. Webb wrote:

> NOTE: I am a C programmer and new to python, so can anyone comment
> on what the st_ctime value is when os.stat() is called on Windows?

The documentation[1] says:

st_ctime - platform dependent; time of most recent metadata change on
Unix, or the time of creation on Windows) 

[1] http://docs.python.org/library/os#os.stat

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

EOL for Python 3.2?

[David Dillard]

With the release of Python 3.3.0 does that mean the 3.2.x line is now end of 
life?

I've looked for some sort of end of life policy on python.org, but was unable 
to find one.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: EOL for Python 3.2?

[Andrew Berg]

On 2012.09.29 15:03, David Dillard wrote:
> With the release of Python 3.3.0 does that mean the 3.2.x line is now end of 
> life?
No. Old releases get security fixes for years.

> I've looked for some sort of end of life policy on python.org, but was unable 
> to find one.
http://www.python.org/download/releases/

If you go to a version, it will tell you the status. For example, 3.1.x
and 2.6.x still get security fixes, but 2.5.6 is the absolute last
release of 2.5 - it will NOT receive updates of any kind. Unless the
page states otherwise, it is pretty safe to assume that the release is
maintained.
-- 
CPython 3.3.0 | Windows NT 6.1.7601.17835
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Missing library path (WIndows)

[FPEFPE]

On Saturday, September 29, 2012 4:02:13 AM UTC-4, Kwpolska wrote:
> On Sat, Sep 29, 2012 at 4:39 AM, FPEFPE  wrote:
> 
> > Hello -- I am running python from an application, starting it with a call 
> > to the python31.dll
> 
> >
> 
> > I think I am missing something in my path -- any help would be appreciated 
> > -- thanks
> 
> 
> 
> Nope, you are not.
> 
> 
> 
> > File "C:\Python32\Lib\encodings\cp437.py", line 19, in encode
> 
> >
> 
> > return codecs.charmap_encode(input,self.errors,encoding_map)[0]
> 
> >
> 
> > UnicodeEncodeError: 'charmap' codec can't encode characters in position 
> > 2-18: character maps to
> 
> > --
> 
> > http://mail.python.org/mailman/listinfo/python-list
> 
> 
> 
> Python has problems with encoding the arguments to look properly with
> 
> the crappy Windows cmd.exe encodings. They cannot be encoded for some
> 
> reason.  You may need magic, but I’m not quite sure what in Py3k
> 
> (bytestrings?)
> 
> 
> 
> -- 
> 
> Kwpolska 
> 
> stop html mail  | always bottom-post
> 
> www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
> 
> GPG KEY: 5EAAEA16

Hello -- thanks for the reply ... is "magic" a debugging tool?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: write a regex matches 800-555-1212, 555-1212, and also (800) 555-1212.

[Tim Delaney]

On 29 September 2012 20:05, Chris Angelico  wrote:

> On Sat, Sep 29, 2012 at 7:38 PM, Mark Lawrence 
> wrote:
> >
> > My understanding is that Python 3.3 has regressed the performance of ''.
> > Surely the Python devs can speed the performance back up and, just for
> us,
> > use less memory at the same time?
>
> Yes, but to do that we'd have to make Python more Australia-focused
> instead of US-centric. As of Python 3.4, the empty string will be
> lazily evaluated and be delimited by redback spiders instead of
> quotes. That will give a 25% speed and 50% memory usage improvement,
> but you'll need to be careful you don't get bitten
>

Look - the worst that will happen is nausea and painful swelling and maybe
death if you're a very young child.

Personally I voted for the Fierce Snake[1][2] as the delimiter, but it was
voted down as "not Pythonic" enough.
I'm sure they were using that as a euphamism for "Python*ish*" though.

[1] https://en.wikipedia.org/wiki/Inland_Taipan
[2] It's is so pretty:
https://upload.wikimedia.org/wikipedia/commons/f/fe/Fierce_Snake-Oxyuranus_microlepidotus.jpg

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

Re: Should one always add super().__init__() to the __init__?

[Piet van Oostrum]

Chris Angelico  writes:

> On Sun, Sep 30, 2012 at 3:17 AM, Steven D'Aprano
>  wrote:
>> No. Only add code that works and that you need. Arbitrarily adding calls
>> to the superclasses "just in case" may not work:
>>
>> py> class Spam(object):
>> ... def __init__(self, x):
>> ... self.x = x
>> ... super(Spam, self).__init__(x)
>> ...
>> py> x = Spam(1)
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>   File "", line 4, in __init__
>> TypeError: object.__init__() takes no parameters
>
> That's because you're subclassing something that doesn't take
> parameters and giving it parameters. Of course that won't work. The
> normal and logical thing to do is to pass on only the parameters that
> you know the parent class expects... but that implies knowing the
> parent, so it's kinda moot.

It is not necesarily calling the parent class. It calls the initializer
of the next class in the MRO order and what class that is depends on the
actual multiple inheritance structure it is used in, which can depend
on subclasses that you don't know yet. This makes it even worse.
-- 
Piet van Oostrum 
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: write a regex matches 800-555-1212, 555-1212, and also (800) 555-1212.

[Chris Angelico]

On Sun, Sep 30, 2012 at 6:51 AM, Tim Delaney
 wrote:
> Personally I voted for the Fierce Snake[1][2] as the delimiter, but it was
> voted down as "not Pythonic" enough.
> I'm sure they were using that as a euphamism for "Python*ish*" though.
>
> [1] https://en.wikipedia.org/wiki/Inland_Taipan
> [2] It's is so pretty:
> https://upload.wikimedia.org/wikipedia/commons/f/fe/Fierce_Snake-Oxyuranus_microlepidotus.jpg

A tempting idea, but it's rather a large delimiter. We should reserve
that for multi-line strings, I think. Although you may have a problem
with i18n; when you take your code to the southern hemisphere, the
snake will be facing the other way, so what you thought was an
open-quote marker is now a close-quote marker instead. Could get
awkward for naive coders.

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

Re: write a regex matches 800-555-1212, 555-1212, and also (800) 555-1212.

[Tim Delaney]

On 30 September 2012 09:26, Chris Angelico  wrote:

> On Sun, Sep 30, 2012 at 6:51 AM, Tim Delaney
>  wrote:
> > Personally I voted for the Fierce Snake[1][2] as the delimiter, but it
> was
> > voted down as "not Pythonic" enough.
> > I'm sure they were using that as a euphamism for "Python*ish*" though.
> >
> > [1] https://en.wikipedia.org/wiki/Inland_Taipan
> > [2] It's is so pretty:
> >
> https://upload.wikimedia.org/wikipedia/commons/f/fe/Fierce_Snake-Oxyuranus_microlepidotus.jpg
>
> A tempting idea, but it's rather a large delimiter. We should reserve
> that for multi-line strings, I think. Although you may have a problem
> with i18n; when you take your code to the southern hemisphere, the
> snake will be facing the other way, so what you thought was an
> open-quote marker is now a close-quote marker instead. Could get
> awkward for naive coders
>

You seem to have that backwards. With the Oz-centric focus, it's taking
code to the northern hemisphere that's the problem.

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

Compairing filenames in a list

[Kevin Anthony]

I have a list of filenames, and i need to find files with the same
name, different extensions, and split that into tuples.  does anyone have
any suggestions on an easy way to do this that isn't O(n^2)?

-- 
Thanks
Kevin Anthony
www.NoSideRacing.com

Do you use Banshee?
Download the Community Extensions:
http://banshee.fm/download/extensions/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compairing filenames in a list

[Dave Angel]

On 09/29/2012 09:27 PM, Kevin Anthony wrote:
> I have a list of filenames, and i need to find files with the same
> name, different extensions, and split that into tuples.  does anyone have
> any suggestions on an easy way to do this that isn't O(n^2)?
>
>

Sure, collect them in a collections.defaultdict  Use basename for the
key, and a list of names as the data item.

if that's not good enough, show us your code, and why it doesn't work,
and tell us what version of Python you're using.

-- 

DaveA

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

Re: How to get progress in python script.

[Colin J. Williams]

On 28/09/2012 12:26 PM, Rolando Cañer Roblejo wrote:

Hi all,

Please, I need you suggest me a way to get statistics about a progress
of my python script. My python script could take a lot of time
processing a file, so I need a way that an external program check the
progress of the script. My first idea was that the python script write a
temp file showing the progress and the external program can check that
file, but I think might happen file read/write locking issues.

Thanks.

Would the Python profiler meet your need?

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

Re: Should one always add super().__init__() to the __init__?

[Ramchandra Apte]

On Saturday, 29 September 2012 22:47:20 UTC+5:30, Steven D'Aprano  wrote:
> On Sat, 29 Sep 2012 06:27:47 -0700, Ramchandra Apte wrote:
> 
> 
> 
> > Should one always add super().__init__() to the __init__? The reason for
> 
> > this is the possibility of changing base classes (and forgetting to
> 
> > update the __init__).
> 
> 
> 
> No. Only add code that works and that you need. Arbitrarily adding calls 
> 
> to the superclasses "just in case" may not work:
> 
> 
> 
> 
> 
> 
> 
> py> class Spam(object):
> 
> ... def __init__(self, x):
> 
> ... self.x = x
> 
> ... super(Spam, self).__init__(x)
> 
> ...
> 
> py> x = Spam(1)
> 
> Traceback (most recent call last):
> 
>   File "", line 1, in 
> 
>   File "", line 4, in __init__
> 
> TypeError: object.__init__() takes no parameters
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Steven

I forgot something:
I meant super().__init__() or similar
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Editing in IDLE

[peterfarrell66]

Thanks for the responses, Terry and Chris, I'll try the shell, alt-P and I'll 
check out SciTE!

Peter

On Saturday, September 29, 2012 11:35:06 AM UTC-7, Chris Angelico wrote:
> On Sun, Sep 30, 2012 at 3:14 AM,   wrote:
> 
> > Hello to the group!
> 
> >
> 
> > I'm a new Python user and so far I'm enjoying it. One of the many newbie 
> > problems I'm having is I can't edit my code in IDLE once it's run or 
> > there's an error message. I can only copy the code so far, paste at the 
> > bottom and continue coding. Is there something simple I'm missing, or 
> > should I be using a different editor?
> 
> 
> 
> I only ever use IDLE in its interactive mode (at which, imho, it's
> 
> rather better than the default Python interactive mode, as it
> 
> auto-indents). In that mode, you can retrieve previous commands with
> 
> Alt-P - at least, that's the keystroke on Windows, not sure if it's
> 
> different on other platforms.
> 
> 
> 
> For editing code that's to be saved in a .py file, I use SciTE, but a
> 
> lot of people do use IDLE for that too. It's a matter of personal
> 
> preference.
> 
> 
> 
> ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Should one always add super().__init__() to the __init__?

[Steven D'Aprano]

On Sat, 29 Sep 2012 20:14:10 -0700, Ramchandra Apte wrote:

> I forgot something:
> I meant super().__init__() or similar

What about it? Please try to remember that we can't read your mind and 
don't know what you are thinking, we can only work from what you put in 
writing.

There is no difference between super(Class, self).__init__ and 
super().__init__ except that the second version only works in Python 3.



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

Re: Should one always add super().__init__() to the __init__?

[Steven D'Aprano]

On Sun, 30 Sep 2012 04:31:48 +1000, Chris Angelico wrote:

> On Sun, Sep 30, 2012 at 3:17 AM, Steven D'Aprano
>  wrote:
>> No. Only add code that works and that you need. Arbitrarily adding
>> calls to the superclasses "just in case" may not work:
>>
>> py> class Spam(object):
>> ... def __init__(self, x):
>> ... self.x = x
>> ... super(Spam, self).__init__(x) ...
>> py> x = Spam(1)
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>   File "", line 4, in __init__
>> TypeError: object.__init__() takes no parameters
> 
> That's because you're subclassing something that doesn't take parameters
> and giving it parameters. Of course that won't work. The normal and
> logical thing to do is to pass on only the parameters that you know the
> parent class expects... but that implies knowing the parent, so it's
> kinda moot.

Which is exactly my point -- you can't call the superclass "just in case" 
it changes, because you don't know what arguments the new superclass or 
classes expect. You have to tailor the arguments to what the parent 
expects, and even whether or not you have to call super at all.[1]

super() is not some magic command "don't bother me with the details, just 
make method overriding work". You have to actually think about what you 
are overriding. You can't expect to take a class that inherits from dict 
and change it to inherit from collections.defaultdict and have super 
magically sort out the differences in __init__.

The usual advise given for using super is:

* the method being called by super() needs to exist
* the caller and callee need to have a matching[2] argument signature
* and every occurrence of the method needs to use super()

If all three conditions apply, then yes, you should use super. Otherwise, 
perhaps not.

For further discussion and practical examples, see:

http://rhettinger.wordpress.com/2011/05/26/super-considered-super/


For a contrary argument, or at least a look at how NOT to use super, see:

https://fuhm.net/super-harmful/

which makes the mistake of blaming super() for mistakes made by people 
who don't use it correctly. Note that the author has back-peddled from 
his original argument that super was actively harmful to a less 
provocative argument that "you can't use super" (except you actually can: 
if you read past the first paragraph, the author tells you exactly what 
you need to do to use super correctly).




[1] You *should* call super, unless you have an excellent reason not to, 
so that your class doesn't break multiple-inheritance. But you need to do 
so with care making sure that the argument signatures are designed for 
cooperative use of super.

[2] Matching in this case does not necessarily mean identical.

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

Re: Should one always add super().__init__() to the __init__?

[Steven D'Aprano]

On Sat, 29 Sep 2012 17:51:29 -0400, Piet van Oostrum wrote:

> It is not necesarily calling the parent class. It calls the initializer
> of the next class in the MRO order and what class that is depends on the
> actual multiple inheritance structure it is used in, which can depend on
> subclasses that you don't know yet. This makes it even worse.

I don't quite follow you here. It sounds like you are saying that if you 
have these classes:

# pre-existing classes
class A(object): pass
class B(object): pass

# your class
class C(A, B): pass

and somebody subclasses A or B, the MRO of C will change. That is not 
actually the case as far as I can see.



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

Re: Should one always add super().__init__() to the __init__?

[Chris Angelico]

On Sun, Sep 30, 2012 at 2:37 PM, Steven D'Aprano
 wrote:
> Which is exactly my point -- you can't call the superclass "just in case"
> it changes, because you don't know what arguments the new superclass or
> classes expect. You have to tailor the arguments to what the parent
> expects, and even whether or not you have to call super at all.[1]
>
> super() is not some magic command "don't bother me with the details, just
> make method overriding work". You have to actually think about what you
> are overriding.

Yeah. Far as I'm concerned, subclassing should *always* involve
knowing the parent class. You needn't concern yourself with its
implementation (I can subclass dict without caring about the details
of hash randomization), but you have to be aware of its interface. And
if you change the base class without changing your method chaining,
you'd better be changing to a new base class that's equivalent to the
old one.

The advantage of super() is that you can substitute a subclass of X as
a new base class without changing anything. But you need to be sure
that the replacement base class obeys the Liskov Substitution
Principle.

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

Re: Should one always add super().__init__() to the __init__?

[Ramchandra Apte]

On Sunday, 30 September 2012 09:53:45 UTC+5:30, Steven D'Aprano  wrote:
> On Sat, 29 Sep 2012 20:14:10 -0700, Ramchandra Apte wrote:
> 
> 
> 
> > I forgot something:
> 
> > I meant super().__init__() or similar
> 
> 
> 
> What about it? Please try to remember that we can't read your mind and 
> 
> don't know what you are thinking, we can only work from what you put in 
> 
> writing.
> 
> 
> 
> There is no difference between super(Class, self).__init__ and 
> 
> super().__init__ except that the second version only works in Python 3.
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Steven

When I said "super().__init__()" it could have been "super().__init__(size+67)" 
or whatever arguments are needed for __init__
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: EOL for Python 3.2?

[Terry Reedy]

On 9/29/2012 4:03 PM, David Dillard wrote:

With the release of Python 3.3.0 does that mean the 3.2.x line is now
end of life?


The next release (3.2.4, soon) will by the last 3.2 bugfix. Then 3 years 
for security fixes.



I've looked for some sort of end of life policy on python.org, but
was unable to find one.


Don't know where written, but last 3.x bugfix about the time of 
3.(x+1).0 and 3 years security is standard.


--
Terry Jan Reedy

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

Re: Should one always add super().__init__() to the __init__?

[Ian Kelly]

On Sat, Sep 29, 2012 at 10:40 PM, Steven D'Aprano
 wrote:
> On Sat, 29 Sep 2012 17:51:29 -0400, Piet van Oostrum wrote:
>
>> It is not necesarily calling the parent class. It calls the initializer
>> of the next class in the MRO order and what class that is depends on the
>> actual multiple inheritance structure it is used in, which can depend on
>> subclasses that you don't know yet. This makes it even worse.
>
> I don't quite follow you here. It sounds like you are saying that if you
> have these classes:
>
> # pre-existing classes
> class A(object): pass
> class B(object): pass
>
> # your class
> class C(A, B): pass
>
> and somebody subclasses A or B, the MRO of C will change. That is not
> actually the case as far as I can see.

The MRO of C will not change, but the class that follows C may be
different in the MRO of a subclass.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Should one always add super().__init__() to the __init__?

[Ian Kelly]

On Sat, Sep 29, 2012 at 10:55 PM, Ramchandra Apte
 wrote:
> When I said "super().__init__()" it could have been 
> "super().__init__(size+67)" or whatever arguments are needed for __init__

But if you change the base class, couldn't those arguments change?
Then you would have to change the call whether super is used or not.
I believe this is what Steven is getting at.
-- 
http://mail.python.org/mailman/listinfo/python-list