Kivy Contest 2014

[jimish]

hey guys,
I have already enrolled to kivy contest 2014 few days ago. Now theme is out, 
How can I know that I have successfully enrolled in kivy contest?

I didnt get any mail from kivy having confirmation of enrollment.

According to instructions i have read earlier, I wanted to ask that are there 2 
persons allowed in a team?

Thanks in advance.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Kivy Contest 2014

[Chris Angelico]

On Tue, Apr 15, 2014 at 5:36 PM,   wrote:
> I have already enrolled to kivy contest 2014 few days ago. Now theme is out, 
> How can I know that I have successfully enrolled in kivy contest?
>
> I didnt get any mail from kivy having confirmation of enrollment.
>
> According to instructions i have read earlier, I wanted to ask that are there 
> 2 persons allowed in a team?

These are Kivy questions, not Python ones. I'd advise trying here:

http://kivy.org/docs/contact.html

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

Re: Learner looking for assistance

[Anthony Smith]

On Monday, 14 April 2014 17:43:41 UTC+10, Anthony Smith  wrote:
> Hi All
> 
> 
> 
> I am probably doing something wrong but don't know what 
> 
> Any help would great 
> 
> 
> 
> Code below 
> 
> 
> 
> the calc_total does not return a estimated_total_weight
> 
> 
> 
> if add the estimated_total_weight the rest of the code works 
> 
> 
> 
> I am at a lose as to why ?
> 
> 
> 
> def calc_total(self):
> 
>   amount = 0
> 
>   if self.estimated_weight_hd > 0:
> 
> amount = self.number * self.estimated_weight_hd
> 
>   return amount
> 
>   
> 
>   def save(self):
> 
>   self.estimated_total_weight = self.calc_total()
> 
>   super(SaleNote, self).save()
> 
>   
> 
> def calc_total_price(self):
> 
>   amount_price = 0
> 
>   if self.sale_head > 0:
> 
>   amount_price = self.number * self.sale_head
> 
> return amount_price
> 
> else:
> 
> if self.estimated_total_weight > 0:
> 
> amount_price = self.estimated_total_weight * self.sale_kg
> 
>   return amount_price
> 
> 
> 
> def save(self):
> 
>   self.total_price = self.calc_total_price()
> 
>   super(SaleNote, self).save()
> 
> 
> 
> thanks 
> 
> 
> 
> anthony

Hi 

To see what I am trying go to yambuk.no-ip.org:8000/admin

this will allow hands on what I am what the program does 

username python password test
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Learner looking for assistance

[Chris Angelico]

On Tue, Apr 15, 2014 at 5:52 PM, Anthony Smith
 wrote:
> To see what I am trying go to yambuk.no-ip.org:8000/admin
>
> this will allow hands on what I am what the program does
>

Recommendation: Take the code out of this framework and just run the
scripts manually. From there, you should have an easier job of
figuring out what's happening.

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

Re: Python, Linux, and the setuid bit

[Richard Kettlewell]

Ethan Furman  writes:
> memset(envp_write, 0, ((unsigned int) envp_read -
>(unsigned int) envp_write));

That is a remarkable blunder for a security-critical program.

On a 64-bit platform, the best case outcome is that it will throw away
the top 32 bits of each pointer before doing the subtraction, yielding
the wrong answer if the discarded bits happen to differ.

(There is no limit to the worst case behavior; the effect of converting
a pointer value to an integer type which cannot represent the result is
undefined.)

I would write:

  (envp_read - envp_write) * sizeof *envp_read

-- 
http://www.greenend.org.uk/rjk/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Linux, and the setuid bit

[Chris Angelico]

On Tue, Apr 15, 2014 at 6:00 PM, Richard Kettlewell  
wrote:
> Ethan Furman  writes:
>> memset(envp_write, 0, ((unsigned int) envp_read -
>>(unsigned int) envp_write));
>
> That is a remarkable blunder for a security-critical program.
>
> On a 64-bit platform, the best case outcome is that it will throw away
> the top 32 bits of each pointer before doing the subtraction, yielding
> the wrong answer if the discarded bits happen to differ.

If the pointers are more than 4GB apart, then yes, it'll give the
wrong answer - just as if you'd subtracted and then cast down to an
integer too small for the result. But if they're two pointers inside
the same object (already a requirement for pointer arithmetic) and not
4GB apart, then two's complement arithmetic will give the right result
even if the discarded bits differ. So while you're correct in theory,
in practice it's unlikely to actually be a problem.

> (There is no limit to the worst case behavior; the effect of converting
> a pointer value to an integer type which cannot represent the result is
> undefined.)
>
> I would write:
>
>   (envp_read - envp_write) * sizeof *envp_read

I'd simply cast them to (char *), which will permit the arithmetic
quite happily and look cleaner.

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

Re: Python, Linux, and the setuid bit

[Chris Angelico]

On Tue, Apr 15, 2014 at 6:15 PM, Chris Angelico  wrote:
> then two's complement arithmetic will give the right result
> even if the discarded bits differ.

Clarification: Two's complement isn't the only way this could be done,
but it is the most likely. So, in theory, there are several possible
causes of disaster, but in practice, on any IBM PC compatible
architecture, casting a pointer to an integer will usually take the
lowest N bits, and two's complement arithmetic will be used, and the
environment is unlikely to hit 4GB in size, so the program will
"happen to work" in >99.999% of cases.

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

Re: Learner looking for assistance

[Steven D'Aprano]

On Mon, 14 Apr 2014 00:43:41 -0700, Anthony Smith wrote:


> the calc_total does not return a estimated_total_weight

That's because you don't tell it to. Your calc_total method multiplies by 
estimated_weight_hd which is not the same as estimated_total_weight.

> 
> if add the estimated_total_weight the rest of the code works
> I am at a lose as to why ?

What does "works" mean in this context? What is the code supposed to do, 
and what does it do instead?

Because you have only given us a tiny snippet of code, we have no way of 
running it. Please read this page here:

http://www.sscce.org/


and try to prepare a short, working (in the sense that it runs and 
demonstrates the problem) example.

 
> def calc_total(self):
>   amount = 0
>   if self.estimated_weight_hd > 0:
> amount = self.number * self.estimated_weight_hd
>   return amount

This only adds the weight to amount if it is positive. If it is negative, 
nothing happens. Is that deliberate? Also, I see you have mixed spaces 
and tabs. Please use one, or the other, but never use both. Mixing spaces 
and tabs will give you no end of headaches.


>   def save(self):
>   self.estimated_total_weight = self.calc_total()
>   super(SaleNote, self).save()

This appears to be indented *inside* the calc_total method, but after the 
return statement, it is dead code and will never be executed. Or perhaps 
not -- because you have mixed spaces and tabs, it is very difficult to 
tell.


> def calc_total_price(self):
>   amount_price = 0
>   if self.sale_head > 0:
>   amount_price = self.number * self.sale_head
> return amount_price
> else:
> if self.estimated_total_weight > 0:
> amount_price = self.estimated_total_weight *
> self.sale_kg
>   return amount_price

Without knowing what your code is supposed to do, we cannot tell how it 
is broken. What is self.sale_head? Under what circumstances is is 
negative?



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

Re: Martijn Faassen: The Call of Python 2.8

[wxjmfauth]

Le lundi 14 avril 2014 20:59:37 UTC+2, Ian a écrit :
> On Apr 14, 2014 11:46 AM,  wrote:
> 
> >
> 
> 
> Point of curiosity: if the first 256 codepoints of Unicode happened to 
> correspond to cp1252 instead of Latin-1, would you still object to the FSR?


Yes.

---

cp1252: I'm perfectly understanding, plenty of people are very happy with
that coding scheme.

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

Re: Martijn Faassen: The Call of Python 2.8

[Terry Reedy]

On 4/15/2014 1:03 AM, Marko Rauhamaa wrote:

Terry Reedy :


Any decent system should have 3.4 available now.


Really, now? Which system is that?


3.4.0 was released a month ago with Windows and Mac installers and 
source for everything else. I know Ubuntu was testing the release 
candidate so I presume it is or will very soon have 3.4 officially 
available. Since there was a six month series of alpha, beta, and 
candidate releases, with an approximate final release data, any 
distribution that wanted to be up to date also could be.


This is all quite aside from the fact that one should be able to unpack 
a tarball and 'make xxx'.


--
Terry Jan Reedy

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

Re: Martijn Faassen: The Call of Python 2.8

[Terry Reedy]

On 4/15/2014 2:08 AM, Ben Finney wrote:

Terry Reedy  writes:


The 'mistake' is your OS, whatever it is, not providing 3.3. It is
already so old that it is off bugfix maintenance. Any decent system
should have 3.4 available now.


I think you mean “… should have Python 3.3 available now”, yes?


??? why would you think that??? My installed 3.4.0 for Windows is dated 
March 16.



--
Terry Jan Reedy


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

Re: Learner looking for assistance

[Anthony Smith]

On Tuesday, 15 April 2014 18:29:27 UTC+10, Steven D'Aprano  wrote:
> On Mon, 14 Apr 2014 00:43:41 -0700, Anthony Smith wrote:
> 
> 
> 
> 
> 
> > the calc_total does not return a estimated_total_weight
> 
> 
> 
> That's because you don't tell it to. Your calc_total method multiplies by 
> 
> estimated_weight_hd which is not the same as estimated_total_weight.
> 
> 
> 
> > 
> 
> > if add the estimated_total_weight the rest of the code works
> 
> > I am at a lose as to why ?
> 
> 
> 
> What does "works" mean in this context? What is the code supposed to do, 
> 
> and what does it do instead?
> 
> 
> 
> Because you have only given us a tiny snippet of code, we have no way of 
> 
> running it. Please read this page here:
> 
> 
> 
> http://www.sscce.org/
> 
> 
> 
> 
> 
> and try to prepare a short, working (in the sense that it runs and 
> 
> demonstrates the problem) example.
> 
> 
> 
>  
> 
> > def calc_total(self):
> 
> > amount = 0
> 
> > if self.estimated_weight_hd > 0:
> 
> > amount = self.number * self.estimated_weight_hd
> 
> > return amount
> 
> 
> 
> This only adds the weight to amount if it is positive. If it is negative, 
> 
> nothing happens. Is that deliberate? Also, I see you have mixed spaces 
> 
> and tabs. Please use one, or the other, but never use both. Mixing spaces 
> 
> and tabs will give you no end of headaches.
> 
> 
> 
> 
> 
> > def save(self):
> 
> > self.estimated_total_weight = self.calc_total()
> 
> > super(SaleNote, self).save()
> 
> 
> 
> This appears to be indented *inside* the calc_total method, but after the 
> 
> return statement, it is dead code and will never be executed. Or perhaps 
> 
> not -- because you have mixed spaces and tabs, it is very difficult to 
> 
> tell.
> 
> 
> 
> 
> 
> > def calc_total_price(self):
> 
> > amount_price = 0
> 
> > if self.sale_head > 0:
> 
> > amount_price = self.number * self.sale_head
> 
> > return amount_price
> 
> > else:
> 
> > if self.estimated_total_weight > 0:
> 
> > amount_price = self.estimated_total_weight *
> 
> > self.sale_kg
> 
> > return amount_price
> 
> 
> 
> Without knowing what your code is supposed to do, we cannot tell how it 
> 
> is broken. What is self.sale_head? Under what circumstances is is 
> 
> negative?
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Steven

Sale head is a positive 
if sale head is used the first function is not required 

but if it is not used the first function is used 

then the last function is used to calculate the total price 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: MemoryError in data conversion

[Mok-Kong Shen]

Am 15.04.2014 01:51, schrieb Gregory Ewing:

Mok-Kong Shen wrote:

I have yet a question out of curiosity: Why is my 2nd list structure,
that apparently is too complex for handling by eval and json, seemingly
not a problem for pickle?


Pickle is intended for arbitrary data structures, so it
is designed to be able to handle deeply-nested and/or
recursive data. Eval only has to handle nesting to depths
likely to be encountered in source code. Apparently the
json parser also assumes you're not going to be using
very deep nesting.


What I need is to have my (complicated) list to be put into
a bytearray, do some proceesing, transfer it to the recipient.
The recipient reverses the processing, obtains a bytearray
that is the same as my original one and gets from it the same
list as mine. Using pickle I can manage to do it (in fact I
did try and succeed with my 2nd list), but that's IMHO a
rather unnatural/awkward work-around. (It means that I have
to pickle out the list to a file and read in the content of
the file in order to have it as a bytearray etc. etc.)

M. K. Shen




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

Re: Martijn Faassen: The Call of Python 2.8

[Chris Angelico]

On Tue, Apr 15, 2014 at 6:33 PM, Terry Reedy  wrote:
> On 4/15/2014 2:08 AM, Ben Finney wrote:
>>
>> Terry Reedy  writes:
>>
>>> The 'mistake' is your OS, whatever it is, not providing 3.3. It is
>>> already so old that it is off bugfix maintenance. Any decent system
>>> should have 3.4 available now.
>>
>>
>> I think you mean “… should have Python 3.3 available now”, yes?
>
>
> ??? why would you think that??? My installed 3.4.0 for Windows is dated
> March 16.

Debian's current stable (Wheezy) was released 2013/05/04, and the
latest version release of it (7.4) was 2014/02/08. Both those dates
precede 2014/03/16, so you don't get 3.4 in Wheezy. (Actually, you
don't even get 3.3, presumably because its launch date of 2012/09/29
missed the Wheezy feature freeze in mid-2012.) Debian Jessie (current
testing) ships 3.3 and 3.4, with the 'python3' package giving you 3.3.

Stable OSes won't necessarily be jumping onto 3.4 instantly upon
availability. Debian Squeeze (oldstable, still supported) doesn't even
ship 3.2, all you get is 3.1.3. If you want Arch Linux, you know where
to find it :) And of course, that very stability is what makes it easy
to just "apt-get build-dep python3" and spin up one from source,
possibly even a 3.5-with-except-expressions for the purpose of testing
:)

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

Re: Python, Linux, and the setuid bit

[Richard Kettlewell]

Chris Angelico  writes:
> Richard Kettlewell  wrote:
>> Ethan Furman  writes:
>>> memset(envp_write, 0, ((unsigned int) envp_read -
>>>(unsigned int) envp_write));
>>
>> That is a remarkable blunder for a security-critical program.
>>
>> On a 64-bit platform, the best case outcome is that it will throw away
>> the top 32 bits of each pointer before doing the subtraction, yielding
>> the wrong answer if the discarded bits happen to differ.
>
> If the pointers are more than 4GB apart, then yes, it'll give the
> wrong answer - just as if you'd subtracted and then cast down to an
> integer too small for the result. But if they're two pointers inside
> the same object (already a requirement for pointer arithmetic) and not
> 4GB apart, then two's complement arithmetic will give the right result
> even if the discarded bits differ. So while you're correct in theory,
> in practice it's unlikely to actually be a problem.

This program is on a security boundary, the pathological cases are
precisely the ones the attacker looks for.

(It’s hard to see how an attacker could turn this into a useful attack.
But perhaps the attacker has more imagination than me.)

-- 
http://www.greenend.org.uk/rjk/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Linux, and the setuid bit

[Chris Angelico]

On Tue, Apr 15, 2014 at 7:28 PM, Richard Kettlewell  
wrote:
> This program is on a security boundary, the pathological cases are
> precisely the ones the attacker looks for.
>
> (It’s hard to see how an attacker could turn this into a useful attack.
> But perhaps the attacker has more imagination than me.)

Quite frankly, I don't even care :) It's easy enough to fix the bug.
The idiomatic code will compile without warnings *and* be secure, so
I'm not seeing any reason to use the existing form. All I'm saying is
that it's normally going to happen to work; sure, an attacker might
well be able to get into something (although if you can generate 4GB
of environment, the fact that it doesn't get zeroed is likely to be
less of a concern than the massive DOS potential of a huge env!!), but
casual usage will have it seeming to work. The obvious solution is
right in every possible way, so that's the thing to do moving forward.

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

Re: gdb python core dump file : not in executable format: File format not

[Wesley]

在 2014年4月15日星期二UTC+8上午3时37分58秒，david@gmail.com写道：
> Does this help?
> 
> 
> http://plasmodic.github.io/ecto/ecto/usage/external/debugging.html
> 
> 
> 
> 
> 
> 
> http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsDebugging
> 
> 
> 
> 
> 
> http://downloads.conceptive.be/downloads/camelot/doc/sphinx/build/advanced/debug.html
> 
> 
> 
> 
> http://forums.gentoo.org/viewtopic-p-7123814.html
> 
> 
> 
> 
> On Mon, Apr 14, 2014 at 1:19 AM, Wesley  wrote:
> 
> Hi guys,
> 
>    Today I am debugging an issue related to memory leak.
> 
> I use gdb 7.7 and python 2.7.6 to generate one core dump file from production 
> env.
> 
> 
> 
> And then, just use gdb to debug the coredump upon the same machine.
> 
> Got error that seems not support debug core file using pyton?
> 
> 
> 
> Here is snippet:
> 
> [root@localhost server]# gdb --core  memleak.core
> 
> GNU gdb (GDB) 7.7
> 
> Copyright (C) 2014 Free Software Foundation, Inc.
> 
> License GPLv3+: GNU GPL version 3 or later 
> 
> This is free software: you are free to change and redistribute it.
> 
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> 
> and "show warranty" for details.
> 
> This GDB was configured as "x86_64-unknown-linux-gnu".
> 
> Type "show configuration" for configuration details.
> 
> For bug reporting instructions, please see:
> 
> .
> 
> Find the GDB manual and other documentation resources online at:
> 
> .
> 
> For help, type "help".
> 
> Type "apropos word" to search for commands related to "word".
> 
> [New LWP 25738]
> 
> [New LWP 25739]
> 
> [New LWP 25740]
> 
> [New LWP 25745]
> 
> [New LWP 25746]
> 
> [New LWP 25747]
> 
> [New LWP 25635]
> 
> Core was generated by `python'.
> 
> #0  0x0030016e15e3 in ?? ()
> 
> (gdb) file /root/server/deviceserver.py
> 
> "/root/server/deviceserver.py": not in executable format: File format not 
> recognized
> 
> (gdb) file /root/server/deviceserver
> 
> /root/server/deviceserver: No such file or directory.
> 
> (gdb) file /root/server/deviceserver.py
> 
> "/root/server/deviceserver.py": not in executable format: File format not 
> recognized
> 
> (gdb)
> 
> --
> 
> https://mail.python.org/mailman/listinfo/python-list
> 
> 
> 
> 
> 
> -- 
> David Garvey

Yeah， I use gdb --args /usr/local/bin/python ../xxx.py --core xxx.core
Then, 'run' to start script.
However, the core dump file is actually from a memory leak process,which use 
1.2 G momory, but now, through info proc, I got proc id, and then, shell pmap 
proc_id, only 650M, so, seems this is new started proc, not reload env from the 
core file.

Anything wrong?

Thanks.
Wesley
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Martijn Faassen: The Call of Python 2.8

[Steven D'Aprano]

On Tue, 15 Apr 2014 04:33:24 -0400, Terry Reedy wrote:

> On 4/15/2014 2:08 AM, Ben Finney wrote:
>> Terry Reedy  writes:
>>
>>> The 'mistake' is your OS, whatever it is, not providing 3.3. It is
>>> already so old that it is off bugfix maintenance. Any decent system
>>> should have 3.4 available now.
>>
>> I think you mean “… should have Python 3.3 available now”, yes?
> 
> ??? why would you think that??? My installed 3.4.0 for Windows is dated
> March 16.


Was it provided by Microsoft as part of the OS?

Terry, while enthusiasm for the latest and greatest version of Python is 
a good thing, stability is also a good thing. Not everyone has the luxury 
of being able to jump on the upgrade treadmill and stay on it. If I 
recall correctly, Python 2.6 has just received its last security update 
from Python, but it will continue to receive them from Red Hat for a few 
more years. (Python 2.4 is still receiving security updates from Red Hat, 
and 2.7 will be receiving them until 2024.)

That stability is very valuable to some people -- that's why people use 
(e.g.) Debian, with its promises of multi-year stability, instead of 
Ubuntu, which goes through major version changes three times a week (or 
so sometimes it seems...) That failure to support 3.4 in the OS-provided 
system is not a mistake, it is a feature.


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

Re: MemoryError in data conversion

[Peter Otten]

Gregory Ewing wrote:

> Mok-Kong Shen wrote:
>> I have yet a question out of curiosity: Why is my 2nd list structure,
>> that apparently is too complex for handling by eval and json, seemingly
>> not a problem for pickle?
> 
> Pickle is intended for arbitrary data structures, so it
> is designed to be able to handle deeply-nested and/or
> recursive data. Eval only has to handle nesting to depths
> likely to be encountered in source code. Apparently the
> json parser also assumes you're not going to be using
> very deep nesting.

But pickle does have the same limitation:

>>> def check(load, dump):
... items = []
... try:
... for i in range(10**6):
... assert load(dump(items)) == items
... items = [items]
... except RuntimeError:
... return i
... 
>>> check(json.loads, json.dumps)
994
>>> check(pickle.loads, pickle.dumps)
499

Mok-Kong Shen, for pickle and json you can increase the limit a bit: 

>>> import sys
>>> sys.setrecursionlimit(2000)
>>> check(json.loads, json.dumps)
1994
>>> check(pickle.loads, pickle.dumps)
999

But be careful, if you choose the limit too high you'll see Python react 
like any other C program:

>>> sys.setrecursionlimit(10)
>>> items = []
>>> for i in range(10):
... items = [items]
... 
>>> s = pickle.dumps(items)
Segmentation fault

For literal_eval() the limit is unfortunately hard-coded in the C source.

Mok-Kong Shen wrote:

> What I need is to have my (complicated) list to be put into
> a bytearray, do some proceesing, transfer it to the recipient.
> The recipient reverses the processing, obtains a bytearray
> that is the same as my original one and gets from it the same
> list as mine. Using pickle I can manage to do it (in fact I
> did try and succeed with my 2nd list), but that's IMHO a
> rather unnatural/awkward work-around. (It means that I have
> to pickle out the list to a file and read in the content of
> the file in order to have it as a bytearray etc. etc.)
 
The limit has been increased before, see

http://bugs.python.org/issue1881

and maybe you can get the core developers to increase it again, but 
generally speaking the existence of a recursion limit is the price you pay 
for easy interfacing with C. 

literal_eval() could allocate its stack dynamically, but that would probably 
complicate the code so that return on investment is questionable.


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

Re: Martijn Faassen: The Call of Python 2.8

[Ben Finney]

Terry Reedy  writes:

> 3.4.0 was released a month ago with Windows and Mac installers and
> source for everything else. I know Ubuntu was testing the release
> candidate so I presume it is or will very soon have 3.4 officially
> available. Since there was a six month series of alpha, beta, and
> candidate releases, with an approximate final release data, any
> distribution that wanted to be up to date also could be.

Those assertions assume that:

* operating systems have stable releases every few months; and

* they have a zero-length process to get a stable release of Python into
  the stable OS release; and

* the user is always running the latest stable OS version immediately
  after its release.

When, in reality, the OS team will need quite a long time to ensure the
stable Python release works smoothly with all of the rest of the OS; the
stable release will come some number of months after that assurance
process is complete; and the user will upgrade some wildly varying time
after the stable OS release is complete.

That reality means “any decent OS will have Python 3.4 today” rather
bold, only a month after its release, and eliminates just about all OSen
from “decent” category.

On the other hand, you might have meant “Python 3.4 is available *for*
any decent OS today”; this is a very different thing from the OS having
that version of Python.

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

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

Re: MemoryError in data conversion

[Gregory Ewing]

Mok-Kong Shen wrote:

(It means that I have
to pickle out the list to a file and read in the content of
the file in order to have it as a bytearray etc. etc.)


No, you don't -- pickle.dumps() returns the pickled
data as a bytes object instead of writing it to a file.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Linux, and the setuid bit

[Grant Edwards]

On 2014-04-15, Dave Angel  wrote:

> Your variable 'size' is declared as size_t, which is an integer
> the size of a pointer.

While that may always be true in practice (at least with gcc), I don't
think the C standard requires it.  size_t is guaranteed to be unsigned
with at least 16 bits and sufficiently wide to represent the size of
any object.  It might be possible, in theory, to have an architecture
that used 64-bit pointers but restricted each data space to 32-bits
and therefore could use 32-bit values for size_t.

If you want to declare an integer the size of a pointer, then the
choices are intptr_t (signed), uintptr_t (unsigned), and ptrdiff_t
(signed value representing the difference between to pointers). 

> Not necessarily the same as an int.

Indeed.

-- 
Grant Edwards   grant.b.edwardsYow! Is something VIOLENT
  at   going to happen to a
  gmail.comGARBAGE CAN?
-- 
https://mail.python.org/mailman/listinfo/python-list

random.seed question (not reproducing same sequence)

[Nick Mellor]

Hi guys,

(Python 2.7, Windows 7 64-bit)

Here's a bit of code stress-testing a method addUpdate_special_to_cart. The 
test adds and updates random "specials" (multiple products bundled at an 
advantageous price) of various sizes to thousands of shopping carts, then 
restocks the whole darn lot. The test passes if the stock level afterwards is 
the same as it was before executing the code for all products.

addUpdate_special_to_cart is working perfectly. But the test isn't.

The test iterates over the same code twice, once with special_qty==4, once with 
special_qty==0, reseeding the Python random module number generator to a fixed 
seed (a string) between the iterations. special_qty==0 removes the special and 
restocks the products. The test relies on precisely the same random number 
sequence on both runs.

Can you think of a reason why the random number generator should fall out of 
sync between the two iterations? Because that's what's happening by the look of 
it: occasionally products are returned to the wrong stockbin. No "random" 
module method is used anywhere else while this code is executing.

When I assign something non-random to the stockbin parameter, the test passes.

Best wishes,



Nick

for qty in [4, 0]:
random.seed(seed)
for cart in range(test_size):
for special in range(randrange(3)):
s.addUpdate_special_to_cart(cart=cart, 
stockbin=randrange(test_size),

special_id=randrange(test_size), special_qty=qty,

products=[(random.choice(PRODUCTS), random.choice(range(10)))
for r in 
range(randrange(7))])
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: random.seed question (not reproducing same sequence)

[John Gordon]

In  Nick Mellor 
 writes:

> No "random" module method is used anywhere else while this code is
> executing.

Are you sure?  How did you verify this?

-- 
John Gordon Imagine what it must be like for a real medical doctor to
gor...@panix.comwatch 'House', or a real serial killer to watch 'Dexter'.

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

Re: random.seed question (not reproducing same sequence)

[Ned Batchelder]

On 4/15/14 11:54 AM, Nick Mellor wrote:

Hi guys,

(Python 2.7, Windows 7 64-bit)

Here's a bit of code stress-testing a method addUpdate_special_to_cart. The test adds and 
updates random "specials" (multiple products bundled at an advantageous price) 
of various sizes to thousands of shopping carts, then restocks the whole darn lot. The 
test passes if the stock level afterwards is the same as it was before executing the code 
for all products.

addUpdate_special_to_cart is working perfectly. But the test isn't.

The test iterates over the same code twice, once with special_qty==4, once with 
special_qty==0, reseeding the Python random module number generator to a fixed 
seed (a string) between the iterations. special_qty==0 removes the special and 
restocks the products. The test relies on precisely the same random number 
sequence on both runs.

Can you think of a reason why the random number generator should fall out of sync between 
the two iterations? Because that's what's happening by the look of it: occasionally 
products are returned to the wrong stockbin. No "random" module method is used 
anywhere else while this code is executing.

When I assign something non-random to the stockbin parameter, the test passes.

Best wishes,



Nick

for qty in [4, 0]:
 random.seed(seed)
 for cart in range(test_size):
 for special in range(randrange(3)):
 s.addUpdate_special_to_cart(cart=cart, 
stockbin=randrange(test_size),
 
special_id=randrange(test_size), special_qty=qty,
 
products=[(random.choice(PRODUCTS), random.choice(range(10)))
 for r in 
range(randrange(7))])



The best way to ensure repeatability of random numbers is to avoid the 
module-level functions, and instead create your own random.Random() 
instance to generate numbers.  Then you can be certain it isn't being 
used by anything else.


--
Ned Batchelder, http://nedbatchelder.com

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

Re: Martijn Faassen: The Call of Python 2.8

[Albert-Jan Roskam]

- Original Message -

> From: Terry Reedy 
> To: python-list@python.org
> Cc: 
> Sent: Tuesday, April 15, 2014 10:32 AM
> Subject: Re: Martijn Faassen: The Call of Python 2.8
> 
> On 4/15/2014 1:03 AM, Marko Rauhamaa wrote:
>>  Terry Reedy :
>> 
>>>  Any decent system should have 3.4 available now.
>> 
>>  Really, now? Which system is that?
> 
> 3.4.0 was released a month ago with Windows and Mac installers and 
> source for everything else. I know Ubuntu was testing the release 
> candidate so I presume it is or will very soon have 3.4 officially 
> available. Since there was a six month series of alpha, beta, and 
> candidate releases, with an approximate final release data, any 
> distribution that wanted to be up to date also could be.
> 
> This is all quite aside from the fact that one should be able to unpack 
> a tarball and 'make xxx'.

True, but in Debian Linux (so probably also Linux) one needs to install some 
zlib packages and some other stuff (https related IIRC) before compiling Python 
(at least with 3.3). 

So glad that pip (and setuptools too?) is part of the standard library in 
Python 3.4 (the zlib error became apparent when installing pip)

Albert-Jan

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

Re: random.seed question (not reproducing same sequence)

[Peter Otten]

Nick Mellor wrote:

> Hi guys,
> 
> (Python 2.7, Windows 7 64-bit)
> 
> Here's a bit of code stress-testing a method addUpdate_special_to_cart.
> The test adds and updates random "specials" (multiple products bundled at
> an advantageous price) of various sizes to thousands of shopping carts,
> then restocks the whole darn lot. The test passes if the stock level
> afterwards is the same as it was before executing the code for all
> products.
> 
> addUpdate_special_to_cart is working perfectly. But the test isn't.
> 
> The test iterates over the same code twice, once with special_qty==4, once
> with special_qty==0, reseeding the Python random module number generator
> to a fixed seed (a string) between the iterations. special_qty==0 removes
> the special and restocks the products. The test relies on precisely the
> same random number sequence on both runs.
> 
> Can you think of a reason why the random number generator should fall out
> of sync between the two iterations? Because that's what's happening by the
> look of it: occasionally products are returned to the wrong stockbin. No
> "random" module method is used anywhere else while this code is executing.
> 
> When I assign something non-random to the stockbin parameter, the test
> passes.
> 
> Best wishes,
> 
> 
> 
> Nick
> 
> for qty in [4, 0]:
> random.seed(seed)
> for cart in range(test_size):
> for special in range(randrange(3)):
> s.addUpdate_special_to_cart(cart=cart,
> stockbin=randrange(test_size),
> 
special_id=randrange(test_size),
> special_qty=qty,
> 
products=[(random.choice(PRODUCTS),
> 
random.choice(range(10)))
> for r in
> 
range(randrange(7))])

An exotic option: I notice that randrange() is the only random function not 
qualified with the module name. If you are using a fancy auto-reloading web 
framework things can get out of sync:

>>> import random
>>> from random import randrange
>>> random.seed(42)
>>> [randrange(10) for _ in range(5)]
[6, 0, 2, 2, 7]
>>> random.seed(42)
>>> [randrange(10) for _ in range(5)]
[6, 0, 2, 2, 7]
>>> reload(random)

>>> random.seed(42)
>>> [randrange(10) for _ in range(5)]
[6, 8, 0, 4, 0]


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

Simple question

[Phil Dobbin]

Hi, all.

I've just started to learn Python (I'm reading Mark Lutz's 'Learning
Python' from O'Reilly) & I'm confused as to this part:

'>>> 0.1 + 0.1 + 0.1 - 0.3
5.55111.'

Using 'import Decimal' you can get a much closer result i.e.
'Decimal('0.0')'

What I'm wondering is why the first calculation that arrives at
'5.55111...' is so far out?

Many thanks,

Cheers,

  Phil...

-- 
currently (ab)using
CentOS 6.5, Debian Squeeze & Wheezy, Fedora 19 & 20, OS X Snow Leopard,
RHEL 7, Ubuntu Precise & Saucy
GnuGPG Key : http://phildobbin.org/publickey.asc
Based in London, UK

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

Re: Simple question

[Zachary Ware]

On Tue, Apr 15, 2014 at 1:18 PM, Phil Dobbin  wrote:
> Hi, all.
>
> I've just started to learn Python (I'm reading Mark Lutz's 'Learning
> Python' from O'Reilly) & I'm confused as to this part:
>
> '>>> 0.1 + 0.1 + 0.1 - 0.3
> 5.55111.'
>
> Using 'import Decimal' you can get a much closer result i.e.
> 'Decimal('0.0')'
>
> What I'm wondering is why the first calculation that arrives at
> '5.55111...' is so far out?

First, note that the "..." part of "5.55111..." is very important
here, it's actually "5.55111...e-17" which means it's really
approximately 0.55111, which is really very close to
the answer you'd expect from a human.  To learn more about why Python
doesn't give 0.0, read this:
https://docs.python.org/3/tutorial/floatingpoint.html

Hope this helps,
-- 
Zach
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Simple question

[Chris Angelico]

On Wed, Apr 16, 2014 at 4:18 AM, Phil Dobbin  wrote:
> '>>> 0.1 + 0.1 + 0.1 - 0.3
> 5.55111.'
>
> What I'm wondering is why the first calculation that arrives at
> '5.55111...' is so far out?

There's something you're not seeing here. In full, the output I see is:

>>> 0.1 + 0.1 + 0.1 - 0.3
5.551115123125783e-17

See that bit at the end? "e-17" means "times ten to the -17th power" -
that is, move the decimal point 17 places to the left. So the actual
value is:

>>> "%50.50f"%(0.1 + 0.1 + 0.1 - 0.3)
'0.5551115123125782702118158340454102'

It's not actually as far out as you think; in fact, that's incredibly
close to zero.

A full explanation of why floating point arithmetic does this can be
found in many places on the internet, but the main thing to note is
that it really isn't showing 5.5.

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

Re: Simple question

[Joel Goldstick]

On Apr 15, 2014 2:19 PM, "Phil Dobbin"  wrote:
>
> Hi, all.
>
> I've just started to learn Python (I'm reading Mark Lutz's 'Learning
> Python' from O'Reilly) & I'm confused as to this part:
>
> '>>> 0.1 + 0.1 + 0.1 - 0.3
> 5.55111.'
>
It's not. Look at the end of the result. It's scientific notation for a
very small number
> Using 'import Decimal' you can get a much closer result i.e.
> 'Decimal('0.0')'
>
> What I'm wondering is why the first calculation that arrives at
> '5.55111...' is so far out?
>
> Many thanks,
>
> Cheers,
>
>   Phil...
>
> --
> currently (ab)using
> CentOS 6.5, Debian Squeeze & Wheezy, Fedora 19 & 20, OS X Snow Leopard,
> RHEL 7, Ubuntu Precise & Saucy
> GnuGPG Key : http://phildobbin.org/publickey.asc
> Based in London, UK
>
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Simple question

[Robert Kern]

On 2014-04-15 19:18, Phil Dobbin wrote:

Hi, all.

I've just started to learn Python (I'm reading Mark Lutz's 'Learning
Python' from O'Reilly) & I'm confused as to this part:

'>>> 0.1 + 0.1 + 0.1 - 0.3
5.55111.'

Using 'import Decimal' you can get a much closer result i.e.
'Decimal('0.0')'

What I'm wondering is why the first calculation that arrives at
'5.55111...' is so far out?


The `...` elides the exponent:

  >>> 0.1 + 0.1 + 0.1 - 0.3
  5.551115123125783e-17

If you copied that verbatim directly out of a book, that's just sloppy editing.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

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

Re: Simple question

[Phil Dobbin]

On 15/04/2014 19:25, Zachary Ware wrote:

> On Tue, Apr 15, 2014 at 1:18 PM, Phil Dobbin  wrote:
>> Hi, all.
>>
>> I've just started to learn Python (I'm reading Mark Lutz's 'Learning
>> Python' from O'Reilly) & I'm confused as to this part:
>>
>> '>>> 0.1 + 0.1 + 0.1 - 0.3
>> 5.55111.'
>>
>> Using 'import Decimal' you can get a much closer result i.e.
>> 'Decimal('0.0')'
>>
>> What I'm wondering is why the first calculation that arrives at
>> '5.55111...' is so far out?
> 
> First, note that the "..." part of "5.55111..." is very important
> here, it's actually "5.55111...e-17" which means it's really
> approximately 0.55111, which is really very close to
> the answer you'd expect from a human.  To learn more about why Python
> doesn't give 0.0, read this:
> https://docs.python.org/3/tutorial/floatingpoint.html
> 
> Hope this helps,
> 

Hi, Zach.

I saw the 'e-17' appended to the end but was unsure of its meaning (
quite a number of things are introduced in the book with clarification
of their meaning not forthcoming 'til later on).

Thank you for the link. It'll be very helpful.

Cheers,

  Phil...

-- 
currently (ab)using
CentOS 6.5, Debian Squeeze & Wheezy, Fedora 19 & 20, OS X Snow Leopard,
RHEL 7, Ubuntu Precise & Saucy
GnuGPG Key : http://phildobbin.org/publickey.asc
Based in London, UK


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

Re: Simple question

[Tim Chase]

On 2014-04-15 19:18, Phil Dobbin wrote:
> I'm confused as to this part:
> 
> '>>> 0.1 + 0.1 + 0.1 - 0.3  
> 5.55111.'
>
> What I'm wondering is why the first calculation that arrives at
> '5.55111...' is so far out?

You omit one key detail in your "", the "e-17" which means that
is 5.55111... times 10^-17 which is a REALLY small number.  To
better show that, have it formatted to place:

  >>> "%55.55f" % (0.1 + 0.1 + 0.1 - 0.3)
  '0.555111512312578270211815834045410156250'

For most engineering purposes, that's effectively zero.

It comes about because of how floating-point numbers are represented
internally.  You can read a lot more than anybody should want to
know at [1].  By using the Decimal module, you remove some of that
imprecision.

-tkc

[1] http://en.wikipedia.org/wiki/Ieee_float





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

Re: Martijn Faassen: The Call of Python 2.8

[Mark H Harris]

On 4/14/14 2:32 PM, Phil Dobbin wrote:

On a related note, Guido announced today that there will be no 2.8 &
that the eol for 2.7 will be 2020.



Can you site the announcement?

Thanks

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

Re: Simple question

[Phil Dobbin]

On 15/04/2014 19:30, Robert Kern wrote:

> On 2014-04-15 19:18, Phil Dobbin wrote:
>> Hi, all.
>>
>> I've just started to learn Python (I'm reading Mark Lutz's 'Learning
>> Python' from O'Reilly) & I'm confused as to this part:
>>
>> '>>> 0.1 + 0.1 + 0.1 - 0.3
>> 5.55111.'
>>
>> Using 'import Decimal' you can get a much closer result i.e.
>> 'Decimal('0.0')'
>>
>> What I'm wondering is why the first calculation that arrives at
>> '5.55111...' is so far out?
> 
> The `...` elides the exponent:
> 
>   >>> 0.1 + 0.1 + 0.1 - 0.3
>   5.551115123125783e-17
> 
> If you copied that verbatim directly out of a book, that's just sloppy
> editing.
> 

No, the ellipses are sloppy editing on my part done purely for brevity.
Unfortunately they elided the relevant part, the meaning of which was,
prior to these conversations, lost on me.

Thanks to all who replied.

Cheers,

  Phil...

-- 
currently (ab)using
CentOS 6.5, Debian Squeeze & Wheezy, Fedora 19 & 20, OS X Snow Leopard,
RHEL 7, Ubuntu Precise & Saucy
GnuGPG Key : http://phildobbin.org/publickey.asc
Based in London, UK


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

Re: Simple question

[Chris Angelico]

On Wed, Apr 16, 2014 at 4:31 AM, Phil Dobbin  wrote:
> I saw the 'e-17' appended to the end but was unsure of its meaning (
> quite a number of things are introduced in the book with clarification
> of their meaning not forthcoming 'til later on).

Recommendation: If you don't understand something, keep it there :)
You can just copy and paste from the Python interactive interpreter
(command line or IDLE) straight into the email; it'll be easier to
explain, that way.

This is *especially* true of tracebacks. You might not see the
difference, but to us, it's often hugely helpful to see the entire
exception report.

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

Re: Martijn Faassen: The Call of Python 2.8

[Terry Reedy]

On 4/15/2014 1:21 PM, Albert-Jan Roskam wrote:


This is all quite aside from the fact that one should be able to
unpack a tarball and 'make xxx'.


True, but in Debian Linux (so probably also Linux) one needs to
install some zlib packages and some other stuff (https related IIRC)
before compiling Python (at least with 3.3).


On windows, I can compile Python without the 3rd party dependencies 
installed. (They are also mostly installed by one .bat file.) The 
compiler will report errors for what is missing, and the corresponding 
imports (like 'import zlib') from the missing dlls will fail, but 
python.exe is built and otherwise runs fine. Are things different on 
*nix -- all or nothing?


In any case, once the dependencies are installed, they should still be 
there if one upgrades with patch release.



So glad that pip (and setuptools too?) is part of the standard
library in Python 3.4 (the zlib error became apparent when installing
pip)


--
Terry Jan Reedy

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

Re: Simple question

[Phil Dobbin]

On 15/04/2014 19:41, Chris Angelico wrote:

> On Wed, Apr 16, 2014 at 4:31 AM, Phil Dobbin  wrote:
>> I saw the 'e-17' appended to the end but was unsure of its meaning (
>> quite a number of things are introduced in the book with clarification
>> of their meaning not forthcoming 'til later on).
> 
> Recommendation: If you don't understand something, keep it there :)
> You can just copy and paste from the Python interactive interpreter
> (command line or IDLE) straight into the email; it'll be easier to
> explain, that way.
> 
> This is *especially* true of tracebacks. You might not see the
> difference, but to us, it's often hugely helpful to see the entire
> exception report.

Good advice.

Truth is I'm writing emails on my laptop & attempting Python on a
Desktop machine so I lazily copied by eye. My mistake.

Cheers,

  Phil...

-- 
currently (ab)using
CentOS 6.5, Debian Squeeze & Wheezy, Fedora 19 & 20, OS X Snow Leopard,
RHEL 7, Ubuntu Precise & Saucy
GnuGPG Key : http://phildobbin.org/publickey.asc
Based in London, UK


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

Re: Simple question

[Phil Dobbin]

On 15/04/2014 20:07, Chris Angelico wrote:

> On Wed, Apr 16, 2014 at 5:02 AM, Phil Dobbin  wrote:
>> On 15/04/2014 19:41, Chris Angelico wrote:
>>
>>> Recommendation: If you don't understand something, keep it there :)
>>> You can just copy and paste from the Python interactive interpreter
>>> (command line or IDLE) straight into the email; it'll be easier to
>>> explain, that way.
>>>
>>> This is *especially* true of tracebacks. You might not see the
>>> difference, but to us, it's often hugely helpful to see the entire
>>> exception report.
>>
>> Good advice.
>>
>> Truth is I'm writing emails on my laptop & attempting Python on a
>> Desktop machine so I lazily copied by eye. My mistake.
> 
> Understandable. I currently am using two consoles (laptop at my right
> hand, desktop in front of me), and every now and then I want to copy
> and paste across them :) I mean, shared clipboard works just fine
> across all my VM guests (and as I type that, Disney's cast is singing
> "Be our guest" in my background music), it even works across remote
> desktop, but for some reason, swinging my hands 90 degrees doesn't
> transfer the clipboard. This strikes me as a major flaw in human
> beings.

:-)

Couldn't agree more. Not enough thought put into that one whoever did it :-)

Cheers,

  Phil...

-- 
currently (ab)using
CentOS 6.5, Debian Squeeze & Wheezy, Fedora 19 & 20, OS X Snow Leopard,
RHEL 7, Ubuntu Precise & Saucy
GnuGPG Key : http://phildobbin.org/publickey.asc
Based in London, UK


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

Re: Simple question

[Chris Angelico]

On Wed, Apr 16, 2014 at 5:02 AM, Phil Dobbin  wrote:
> On 15/04/2014 19:41, Chris Angelico wrote:
>
>> Recommendation: If you don't understand something, keep it there :)
>> You can just copy and paste from the Python interactive interpreter
>> (command line or IDLE) straight into the email; it'll be easier to
>> explain, that way.
>>
>> This is *especially* true of tracebacks. You might not see the
>> difference, but to us, it's often hugely helpful to see the entire
>> exception report.
>
> Good advice.
>
> Truth is I'm writing emails on my laptop & attempting Python on a
> Desktop machine so I lazily copied by eye. My mistake.

Understandable. I currently am using two consoles (laptop at my right
hand, desktop in front of me), and every now and then I want to copy
and paste across them :) I mean, shared clipboard works just fine
across all my VM guests (and as I type that, Disney's cast is singing
"Be our guest" in my background music), it even works across remote
desktop, but for some reason, swinging my hands 90 degrees doesn't
transfer the clipboard. This strikes me as a major flaw in human
beings.

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

Re: Martijn Faassen: The Call of Python 2.8

[Terry Reedy]

On 4/15/2014 7:33 AM, Ben Finney wrote:

Terry Reedy  writes:


3.4.0 was released a month ago with Windows and Mac installers and
source for everything else. I know Ubuntu was testing the release
candidate so I presume it is or will very soon have 3.4 officially
available. Since there was a six month series of alpha, beta, and
candidate releases, with an approximate final release data, any
distribution that wanted to be up to date also could be.


Those assertions assume that:

* operating systems have stable releases every few months; and

* they have a zero-length process to get a stable release of Python into
   the stable OS release; and

* the user is always running the latest stable OS version immediately
   after its release.


No, I was not talking about replacing the system python. Only about 
having a .rpm or .deb or whatever available to make an alternate 
install. My comments are a response to someone saying he could not use 
Python3 because his system only had ancient 3.2 available and he needed 
to use a module that requires 3.3. If he was telling the truth, this 
strikes me as ridiculous.



When, in reality, the OS team will need quite a long time to ensure the
stable Python release works smoothly with all of the rest of the OS;


For a standalone non-system install, I cannot imagine what you are 
talking about. CPython is primarily developed on Linux. It is continuous 
tested on multiple buildbots that include several *nix and in particular 
linux distributions (https://www.python.org/dev/buildbot/). I believe it 
more stable on linux than anything else, certainly more than on Windows. 
CPython x.y.0 is released after a month of candidate testing. When it is 
released, it definitely works on multiple linux distributions, or it 
would not be released.


I believe distutils has options to create some package manager bundles 
(.rpm, .deb?, ???) and that we once hosted such on the site on day 1, 
along with a windows binary. I believe we no longer do because linux 
distributions proliferated and said that they would rather host python 
bundles in their own package manager systems.



--
Terry Jan Reedy

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

Re: Martijn Faassen: The Call of Python 2.8

[Terry Reedy]

On 4/15/2014 2:32 PM, Mark H Harris wrote:

On 4/14/14 2:32 PM, Phil Dobbin wrote:

On a related note, Guido announced today that there will be no 2.8 &
that the eol for 2.7 will be 2020.



Can you site the announcement?


It is part of a thread on pydev list.


--
Terry Jan Reedy

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

Re: Martijn Faassen: The Call of Python 2.8

[Novocastrian_Nomad]

On Tuesday, April 15, 2014 12:32:14 PM UTC-6, Mark H. Harris wrote:
> On 4/14/14 2:32 PM, Phil Dobbin wrote:
> > On a related note, Guido announced today that there will be no 2.8 &
> > that the eol for 2.7 will be 2020.
> >
>
> Can you site the announcement?
> 
> Thanks

http://hg.python.org/peps/rev/76d43e52d978?utm_content=buffer55d59&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer
-- 
https://mail.python.org/mailman/listinfo/python-list

The Purpose Of Life & Muslim Spoken Word & The Daily Reminder

[bv4bv4bv4]

The Purpose Of Life &  Muslim Spoken Word & The Daily Reminder 

 

http://www.youtube.com/watch?v=Wdhk2y6zFg4


Thank you
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Martijn Faassen: The Call of Python 2.8

[Mark H Harris]

On 4/15/14 2:37 PM, Novocastrian_Nomad wrote:

On Tuesday, April 15, 2014 12:32:14 PM UTC-6, Mark H. Harris wrote:


Can you site the announcement?

Thanks


http://hg.python.org/peps/rev/76d43e52d978?utm_content=buffer55d59&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer



Thanks, guys.

I am noticing the call to 2.8 from time to time (blogs). All along I 
have been seeing the reluctance to migrate to 3.x as either stubborn or 
lazy; or both.


I don't think so any longer. Seems like the reluctance to migrate stems 
from dependencies. Is there a list of primary dependencies ?


As an example:  Is 'twisted' a dependency? ie., twisted does not support 
3.x consequently 'I' can't port my stuff to 3.x because 'twisted' isn't 
there yer.  There are others, gevent, maybe. Has anyone taken an 
inventory of dependencies that must support 3.x before other code(s) can 
be ported?  Maybe there could be an on-line questionnaire regarding 
perceived dependencies?


marcus
--
https://mail.python.org/mailman/listinfo/python-list

Re: Martijn Faassen: The Call of Python 2.8

[Terry Reedy]

On 4/15/2014 5:05 AM, Chris Angelico wrote:

On Tue, Apr 15, 2014 at 6:33 PM, Terry Reedy  wrote:

On 4/15/2014 2:08 AM, Ben Finney wrote:


Terry Reedy  writes:


The 'mistake' is your OS, whatever it is, not providing 3.3. It is
already so old that it is off bugfix maintenance. Any decent system
should have 3.4 available now.



I think you mean “… should have Python 3.3 available now”, yes?



??? why would you think that??? My installed 3.4.0 for Windows is dated
March 16.


Debian's current stable (Wheezy) was released 2013/05/04, and the
latest version release of it (7.4) was 2014/02/08. Both those dates
precede 2014/03/16, so you don't get 3.4 in Wheezy. (Actually, you
don't even get 3.3, presumably because its launch date of 2012/09/29
missed the Wheezy feature freeze in mid-2012.) Debian Jessie (current
testing) ships 3.3 and 3.4, with the 'python3' package giving you 3.3.


There are three things a distribution can do with a new Python version:
1. Push it on people.
2. Allow people who need it to easily get it.
3. Actively hide it and discourage its use.

I happen to think 2) is generally the right answer.

--
Terry Jan Reedy


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

Re: Martijn Faassen: The Call of Python 2.8

[Terry Reedy]

On 4/15/2014 3:54 PM, Mark H Harris wrote:


I don't think so any longer. Seems like the reluctance to migrate stems
from dependencies. Is there a list of primary dependencies ?



https://python3wos.appspot.com/

--
Terry Jan Reedy

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

Re: Martijn Faassen: The Call of Python 2.8

[Ned Batchelder]

On 4/15/14 3:54 PM, Mark H Harris wrote:

On 4/15/14 2:37 PM, Novocastrian_Nomad wrote:

On Tuesday, April 15, 2014 12:32:14 PM UTC-6, Mark H. Harris wrote:


Can you site the announcement?

Thanks


http://hg.python.org/peps/rev/76d43e52d978?utm_content=buffer55d59&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer




Thanks, guys.

I am noticing the call to 2.8 from time to time (blogs). All along I
have been seeing the reluctance to migrate to 3.x as either stubborn or
lazy; or both.

I don't think so any longer. Seems like the reluctance to migrate stems
from dependencies. Is there a list of primary dependencies ?

As an example:  Is 'twisted' a dependency? ie., twisted does not support
3.x consequently 'I' can't port my stuff to 3.x because 'twisted' isn't
there yer.  There are others, gevent, maybe. Has anyone taken an
inventory of dependencies that must support 3.x before other code(s) can
be ported?  Maybe there could be an on-line questionnaire regarding
perceived dependencies?


The Python Wall-Of-Shame/Wall-Of-Superpowers shows popular packages, and 
their Python 3 status:  http://python3wos.appspot.com/




marcus



--
Ned Batchelder, http://nedbatchelder.com

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

Re: Martijn Faassen: The Call of Python 2.8

[Joshua Landau]

On 15 April 2014 06:03, Marko Rauhamaa  wrote:
> Terry Reedy :
>
>> Any decent system should have 3.4 available now.
>
> Really, now? Which system is that?

Arch is on 3.4 *default*.

$> python
Python 3.4.0 (default, Mar 17 2014, 23:20:09)
[...]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Martijn Faassen: The Call of Python 2.8

[Ned Batchelder]

On 4/15/14 5:34 PM, Joshua Landau wrote:

On 15 April 2014 06:03, Marko Rauhamaa  wrote:

Terry Reedy :


Any decent system should have 3.4 available now.


Really, now? Which system is that?


Arch is on 3.4 *default*.

 $> python
 Python 3.4.0 (default, Mar 17 2014, 23:20:09)
 [...]



Yeah, that's the wrong way to do it, and they shouldn't have done that. 
 "python" needs to mean Python 2.x for a long time.


--
Ned Batchelder, http://nedbatchelder.com

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

Re: Martijn Faassen: The Call of Python 2.8

[Mark H Harris]

On 4/15/14 4:02 PM, Terry Reedy wrote:


https://python3wos.appspot.com/



That's what I thought. Its really about getting the super-power wall 
fixed up; everything else will fall in place. I do think that Guido 
might be positioning himself as an enabler, of sorts. I can see 
extending through 2015... I think extending support for 2.7 through 2020 
is ridiculous.


The trouble with the super-power wall is that if Guido extends t 
much, the super-powers will slack off because the dead-line appears 
further out than it really is. All I'm saying is a little pressure might 
be a good thing.


marcus

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

Re: Martijn Faassen: The Call of Python 2.8

[Andrew Berg]

On 2014.04.15 16:02, Terry Reedy wrote:
> https://python3wos.appspot.com/
There seems to be a difference of opinion between this page and the Twisted 
devs on what the "Python 2 only" classifier for PyPI means.

-- 
CPython 3.4.0 | Windows NT 6.2.9200 / FreeBSD 10.0
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Martijn Faassen: The Call of Python 2.8

[Andrew Berg]

On 2014.04.15 17:18, Ned Batchelder wrote:
> Yeah, that's the wrong way to do it, and they shouldn't have done that. 
>   "python" needs to mean Python 2.x for a long time.
Or maybe explicit is better than implicit:

# python
zsh: command not found: python
# which python2.7
/usr/local/bin/python2.7
# which python3.4
/usr/local/bin/python3.4

-- 
CPython 3.4.0 | Windows NT 6.2.9200 / FreeBSD 10.0
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Martijn Faassen: The Call of Python 2.8

[Joshua Landau]

On 15 April 2014 23:18, Ned Batchelder  wrote:
> On 4/15/14 5:34 PM, Joshua Landau wrote:
>> Arch is on 3.4 *default*.
>>
>>  $> python
>>  Python 3.4.0 (default, Mar 17 2014, 23:20:09)
>>  [...]
>>
> Yeah, that's the wrong way to do it, and they shouldn't have done that.
> "python" needs to mean Python 2.x for a long time.

Why?

The only things that break are things outside of the official repos,
and the vast majority of the user repository works flawlessly. If I
get something from the source, I normally run it explicitly ("python
the_thing") and on the very rare occasion it breaks (when it's 2.x and
uses "python" to mean "python2") I can trivially patch or wrap it, and
file a bug report.

The python = python3 choice of Arch is not what takes up maintenance
time, and it's good to prepare developers ahead of time. That's what
rolling release is all about: getting the best and preparing the rest.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: random.seed question (not reproducing same sequence)

[Dan Stromberg]

You could easily provide your own random number generator, if you
don't need cryptographic-strength random numbers.

EG:
http://stromberg.dnsalias.org/svn/lcgrng/trunk/lcgrng.py

That way you can be certain nothing else is using it.


On Tue, Apr 15, 2014 at 8:54 AM, Nick Mellor  wrote:
> Hi guys,
>
> (Python 2.7, Windows 7 64-bit)
>
> Here's a bit of code stress-testing a method addUpdate_special_to_cart. The 
> test adds and updates random "specials" (multiple products bundled at an 
> advantageous price) of various sizes to thousands of shopping carts, then 
> restocks the whole darn lot. The test passes if the stock level afterwards is 
> the same as it was before executing the code for all products.
>
> addUpdate_special_to_cart is working perfectly. But the test isn't.
>
> The test iterates over the same code twice, once with special_qty==4, once 
> with special_qty==0, reseeding the Python random module number generator to a 
> fixed seed (a string) between the iterations. special_qty==0 removes the 
> special and restocks the products. The test relies on precisely the same 
> random number sequence on both runs.
>
> Can you think of a reason why the random number generator should fall out of 
> sync between the two iterations? Because that's what's happening by the look 
> of it: occasionally products are returned to the wrong stockbin. No "random" 
> module method is used anywhere else while this code is executing.
>
> When I assign something non-random to the stockbin parameter, the test passes.
>
> Best wishes,
>
>
>
> Nick
>
> for qty in [4, 0]:
> random.seed(seed)
> for cart in range(test_size):
> for special in range(randrange(3)):
> s.addUpdate_special_to_cart(cart=cart, 
> stockbin=randrange(test_size),
> 
> special_id=randrange(test_size), special_qty=qty,
> 
> products=[(random.choice(PRODUCTS), random.choice(range(10)))
> for r in 
> range(randrange(7))])
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Martijn Faassen: The Call of Python 2.8

[Ned Batchelder]

On 4/15/14 7:11 PM, Joshua Landau wrote:

On 15 April 2014 23:18, Ned Batchelder  wrote:

On 4/15/14 5:34 PM, Joshua Landau wrote:

Arch is on 3.4 *default*.

  $> python
  Python 3.4.0 (default, Mar 17 2014, 23:20:09)
  [...]


Yeah, that's the wrong way to do it, and they shouldn't have done that.
"python" needs to mean Python 2.x for a long time.


Why?

The only things that break are things outside of the official repos,
and the vast majority of the user repository works flawlessly. If I
get something from the source, I normally run it explicitly ("python
the_thing") and on the very rare occasion it breaks (when it's 2.x and
uses "python" to mean "python2") I can trivially patch or wrap it, and
file a bug report.

The python = python3 choice of Arch is not what takes up maintenance
time, and it's good to prepare developers ahead of time. That's what
rolling release is all about: getting the best and preparing the rest.



The problem is files that use shebang lines:

#!/usr/bin/python

or:

#!/usr/bin/env python

If these are Python 2 files, they now don't work.  Keep in mind, these 
might not be files that you have written, they may have been installed 
as part of another package, or written long ago.


For the official statement on "python" meaning Python 2, and more on 
why, see PEP 394: 'The "python" Command on Unix-Like Systems': 
http://legacy.python.org/dev/peps/pep-0394/


--
Ned Batchelder, http://nedbatchelder.com

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

Re: Martijn Faassen: The Call of Python 2.8

[Devin Jeanpierre]

On Tue, Apr 15, 2014 at 4:11 PM, Joshua Landau  wrote:
> On 15 April 2014 23:18, Ned Batchelder  wrote:
>> On 4/15/14 5:34 PM, Joshua Landau wrote:
>>> Arch is on 3.4 *default*.
>>>
>>>  $> python
>>>  Python 3.4.0 (default, Mar 17 2014, 23:20:09)
>>>  [...]
>>>
>> Yeah, that's the wrong way to do it, and they shouldn't have done that.
>> "python" needs to mean Python 2.x for a long time.
>
> Why?
>
> The only things that break are things outside of the official repos,

Yes. Software included in Arch, and programs installed via distutils,
will both work correctly under Arch. However, it breaks any 2.x code
that is expected to run without being installed via distutils and
doesn't use the "python2" executable. Which used to be any 2.x
program, since "python2" originally didn't even exist in many OSes. It
also, at the time of introduction, broke all installed software that
wasn't part of Arch itself.

I have a few problems with what they did. I don't like how Arch
created a situation where it was impossible to support Arch and Debian
at the same time with standalone Python 2.x programs (due to a missing
python2 and differing python in Debian). I don't like how the
migration was not communicated sufficiently clearly to users[*], so
that when they saw weird Python errors, they came to the Python
community instead of to Arch, overwhelming #python (if not other
places) with support requests. (We had to temporarily ban Arch
questions to stop people from asking.)  I don't like how their new and
unusual executable naming scheme forced into existence a PEP [1] to
figure out how to bring Python and Debian into line, and I don't like
how Debian was forced to do extra work to make life easier for Python
2.x developers and resolve problems that only existed because of what
Arch did.

They caused a lot of grief, and for what? As far as I can tell, it's
was a marketing gimmick -- Arch gets to look cool by being "bleeding
edge", and everyone else pays the price.

It's worth stating clearly: there is actually no technical benefit to
changing what the python symlink points to. If we want to do such a
thing, it is for cultural reasons, and there is no urgency to it. It
can be done over an extremely long period of time.

[*] One might also ask why they didn't do a phase where python2 was
python 2.x, python3 was python 3.x, and python was 2.x but also gave a
warning to upgrade your stuff because the meaning of the symlink was
changing. There is no good reason. The stated reason was that warnings
are annoying -- so they broke everything instead of giving warnings. [2]

[1] http://legacy.python.org/dev/peps/pep-0394/
[2] https://mail.python.org/pipermail/python-dev/2010-November/105299.html

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

Re: random.seed question (not reproducing same sequence)

[Ned Batchelder]

On 4/15/14 8:07 PM, Dan Stromberg wrote:

You could easily provide your own random number generator, if you
don't need cryptographic-strength random numbers.

EG:
http://stromberg.dnsalias.org/svn/lcgrng/trunk/lcgrng.py

That way you can be certain nothing else is using it.


There's no need to pull in a new implementation.  The stdlib module is 
perfectly willing to give you your own private random number sequence to 
use.


--
Ned Batchelder, http://nedbatchelder.com

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

Re: random.seed question (not reproducing same sequence)

[Nick Mellor]

Thanks John and others,

Replies much appreciated. I don't know how it could affect the results, but the 
function being tested is using redis. And I am running the test code under 
PyCharm, so perhaps using the module-level random number generator wasn't such 
a good idea. Live and learn.

In response to your question, John, all I know is that my own code doesn't use 
the random module outside of this code fragment.

Ned, thanks for the tip about creating a new instance of Random(). The test 
failures are still happening when the stockbins are randomised (as in code 
below.) That is suggesting that my code is somehow at fault.

Peter, I am using PyCharm as I said. But using a new Random() object to 
generate the sequence doesn't solve the problem apparently. The code now looks 
like this:

rnd = random.Random()
...
for qty in [4, 0]:
rnd.seed(seed)
for cart in range(test_size):
for special in range(rnd.randrange(3)):
s.addUpdate_special_to_cart(cart=cart, 
stockbin=rnd.randrange(test_size),

special_id=rnd.randrange(test_size), special_qty=qty,

products=[(rnd.choice(PRODUCTS), rnd.choice(range(10)))
  for r in 
range(rnd.randrange(7))])


Cheers,

Nick
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Martijn Faassen: The Call of Python 2.8

[Steven D'Aprano]

On Tue, 15 Apr 2014 18:18:16 -0400, Ned Batchelder wrote:

> On 4/15/14 5:34 PM, Joshua Landau wrote:
>> On 15 April 2014 06:03, Marko Rauhamaa  wrote:
>>> Terry Reedy :
>>>
 Any decent system should have 3.4 available now.
>>>
>>> Really, now? Which system is that?
>>
>> Arch is on 3.4 *default*.
>>
>>  $> python
>>  Python 3.4.0 (default, Mar 17 2014, 23:20:09) [...]
>>
>>
> Yeah, that's the wrong way to do it, and they shouldn't have done that.
>   "python" needs to mean Python 2.x for a long time.

That's a matter of opinion :-)

But Arch is considered pretty gung-ho in this matter, even by people 
(like me) who want "python" to mean "the latest version" rather than 
"something old and decrepit". I recall jokes back when Arch first moved 
to Python 3 as their system Python, that Arch was the bleeding-edge Linux 
distro for those who found Slackware too tame and unadventurous.

For the avoidance of doubt: Python 2.7 is not "old and decripit". Yet. 
But some day it will be. When that time comes, I want "python" to mean 
Python 3.6 or 3.7 or 4.2, or whatever is the most recent version, not 2.7 
or 1.5.



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

Re: Martijn Faassen: The Call of Python 2.8

[Steven D'Aprano]

On Tue, 15 Apr 2014 17:32:57 -0500, Andrew Berg wrote:

> On 2014.04.15 17:18, Ned Batchelder wrote:
>> Yeah, that's the wrong way to do it, and they shouldn't have done that.
>>   "python" needs to mean Python 2.x for a long time.
> Or maybe explicit is better than implicit:
> 
> # python
> zsh: command not found: python
> # which python2.7
> /usr/local/bin/python2.7
> # which python3.4
> /usr/local/bin/python3.4

If you really meant that, you would have typed "/usr/bin/which2.16 
python" (or whatever the location and version of which on your system).




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

Re: Martijn Faassen: The Call of Python 2.8

[Joshua Landau]

On 16 April 2014 01:42, Devin Jeanpierre  wrote:
> Yes. Software included in Arch, and programs installed via distutils,
> will both work correctly under Arch. [...]
>
> I don't like how Arch
> created a situation where it was impossible to support Arch and Debian
> at the same time with standalone Python 2.x programs (due to a missing
> python2 and differing python in Debian).

Let the developers aim at Debian and other mainstream distros and Arch
will clean it up for its own use. Isn't that how it normally works?

This did, however, quickly result in "python2" symlinks, which I think
is extremely good in the long run to have ingrained in people's
habits.

>  I don't like how the
> migration was not communicated sufficiently clearly to users[*], so
> that when they saw weird Python errors, they came to the Python
> community instead of to Arch

That's not expected Arch user behaviour ;).

> I don't like how their new and
> unusual executable naming scheme forced into existence a PEP [1] to
> figure out how to bring Python and Debian into line, and I don't like
> how Debian was forced to do extra work to make life easier for Python
> 2.x developers and resolve problems that only existed because of what
> Arch did.

I don't agree entirely. Arch was early, perhaps earlier than
reasonable, but "python2" was going to be needed soon anyway,
especially since it significantly aids adoption of the
version-prepended names.

> It's worth stating clearly: there is actually no technical benefit to
> changing what the python symlink points to. If we want to do such a
> thing, it is for cultural reasons, and there is no urgency to it. It
> can be done over an extremely long period of time.

This is Arch. The fact that it *can* be done over a long period of
time falls far behind the "cultural reasons" in level of importance.

> [*] One might also ask why they didn't do a phase where python2 was
> python 2.x, python3 was python 3.x, and python was 2.x but also gave a
> warning to upgrade your stuff because the meaning of the symlink was
> changing. There is no good reason. The stated reason was that warnings
> are annoying -- so they broke everything instead of giving warnings. [2]
>
> [2] https://mail.python.org/pipermail/python-dev/2010-November/105299.html

Thanks for the read; I found it rather entertaining. Apologies about
the #python grief.

I disagree with you about the warnings. Arch is made to move fast and
this is made abundantly clear:

@https://wiki.archlinux.org/index.php/The_Arch_Way
> This user-centric design necessarily implies a certain "do-it-yourself" 
> approach to using the Arch distribution. Rather than pursuing assistance or 
> requesting a new feature to be implemented by developers, Arch Linux users 
> have a tendency to solve problems themselves and generously share the results 
> with the community and development team – a "do first, then ask" philosophy. 
> This is especially true for user-contributed packages found in the Arch User 
> Repository – the official Arch Linux repository for community-maintained 
> packages.

If people want to run Arch but don't want the Arch way, then there's
not much we can do about it. Arch isn't going to compromise its
demographic because a different demographic is also using it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Martijn Faassen: The Call of Python 2.8

[Steven D'Aprano]

On Tue, 15 Apr 2014 15:48:06 -0400, Terry Reedy wrote:

> On 4/15/2014 5:05 AM, Chris Angelico wrote:
>> On Tue, Apr 15, 2014 at 6:33 PM, Terry Reedy  wrote:
>>> On 4/15/2014 2:08 AM, Ben Finney wrote:

 Terry Reedy  writes:

> The 'mistake' is your OS, whatever it is, not providing 3.3. It is
> already so old that it is off bugfix maintenance. Any decent system
> should have 3.4 available now.


 I think you mean “… should have Python 3.3 available now”, yes?
>>>
>>>
>>> ??? why would you think that??? My installed 3.4.0 for Windows is
>>> dated March 16.
>>
>> Debian's current stable (Wheezy) was released 2013/05/04, and the
>> latest version release of it (7.4) was 2014/02/08. Both those dates
>> precede 2014/03/16, so you don't get 3.4 in Wheezy. (Actually, you
>> don't even get 3.3, presumably because its launch date of 2012/09/29
>> missed the Wheezy feature freeze in mid-2012.) Debian Jessie (current
>> testing) ships 3.3 and 3.4, with the 'python3' package giving you 3.3.
> 
> There are three things a distribution can do with a new Python version:
> 1. Push it on people.
> 2. Allow people who need it to easily get it. 
> 3. Actively hide it and discourage its use.
> 
> I happen to think 2) is generally the right answer.

How would they do #3? Patch all the web browsers to fake a 404 Not Found 
when you go to the Python website and try to download it?

I'm actually asking a serious question. How does a distro "actively hide" 
something publicly available on the Internet? Note that, on Linux (when 
you talk about "distributions", you probably don't mean OS X or Windows) 
all the compiler tools needed to install from source are readily 
available, so anyone who wants to install a Python version not supported 
by their distro can do so. Many people don't wish to install anything 
outside of their distro's supported packages, but that's their choice, 
not the distro imposing anything on them.



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

Re: Martijn Faassen: The Call of Python 2.8

[Steven D'Aprano]

On Tue, 15 Apr 2014 14:54:53 -0500, Mark H Harris wrote:

> I am noticing the call to 2.8 from time to time (blogs). All along I
> have been seeing the reluctance to migrate to 3.x as either stubborn or
> lazy; or both.

Migrating to 3.x can be a fair amount of work. Not as much work as 
migrating to a new language, you get to keep probably 90-99% of the code, 
but it's not always easy either.

Converting "print spam" to "print(spam)" is the trivial part of it. The 
biggest change between Python 2.x and 3.x is the bytes to Unicode shift, 
and that is *not trivial*. Python 2.x tries very hard to make bytes and 
strings interoperate even when doing so is the wrong thing to do. So 
there is a lot of Python 2 code that is *broken* with respect to strings, 
but *seems okay* so long as you only test it using pure ASCII. Python 3 
no longer tries to hide the difference, it forces you to confront the 
fact that bytes and strings are not the same. To people raised on ASCII-
only programming standards, that's a huge paradigm shift, and a confusing 
one. There's a lot to learn, a lot of pain if you don't learn it, and 
there can be a lot of effort needed to migrate string code to Python 3.

(Depending on what your code actually does. It is remarkable just how 
much string code you can write that works identically in 2.x and 3.x. 
Basic string handling remains basic in both.)

The Python ecosystem is a lot bigger than ASCII users, and everyone else 
had to suffer with Python 2's string handling so ASCII users don't have 
to do anything special. With Python 3, everyone is in the same boat. If 
all your data is ASCII, you might be resentful of the need to go to all 
this trouble for no apparent benefit, and resentful of Python 3 forcing 
you to deal it. But whether you are glad of the changes or wish it was 
1959 and you could forget all about the non-ASCII world[1], there is no 
doubt that the effort required can be painful.

So migrating costs time, and effort, and money. If you have a 100-line 
script, your experience is likely to be very different from somebody 
having to migrate a 100,000 line application. People are reluctant to 
spend that sort of time and money without clear benefit, and for many 
people, Python 2 is "good enough". Apart from Unicode, which many people 
do not need, appreciate or even want[2], the benefits of Python 3 are 
incremental, not revolutionary, and the cost/benefit ratio is on the 
wrong side to justify migration.

This is why Python 2.7 has got such extended support, and why the core 
developers are spending so much effort trying to decrease the cost of 
migration and increase the benefit. But, ultimately, some people will 
decide to never migrate their application to 3.x, because the cost will 
always exceed the benefit. That's okay. That's the great thing about 
software. So long as you can find hardware that will run Python 2.7, you 
can keep running 2.7 for ever. Or 2.3, or 1.5.


> I don't think so any longer. Seems like the reluctance to migrate stems
> from dependencies.

Not anymore. Most -- not all, but the majority -- now support 3.x. Now 
the reluctance stems from cost/benefit. If it takes four people a month 
to migrate your application, and you pay them $40 an hour (a relatively 
low price for software developers, I know some who make in the vicinity 
of $200 an hour), that's a direct cost of $25K. Plus the indirect cost of 
stuff that they could have been working on in that time but aren't. Would 
you pay twenty-five thousand dollars for an upgrade that runs a bit 
slower but otherwise has no new functionality that you care about?

This is why Alex Gaynor calls Python 2.7 "the new Cobol". I expect that 
most, but not all, small and medium sized Python applications will 
eventually be migrated to 3.x, and new applications of any size will be 
written in 3.x, but many existing big Python apps will stay on 2.7 
forever. 



[1] The non-ASCII world includes the USA. Even in the US, there are 
common American-English symbols which cannot be written using pure ASCII, 
the most obvious being ¢ the cent symbol.

[2] Sadly, there are still people who consider Unicode to be unnecessary. 
Why can't everyone just learn to write in English? Or if they won't, why 
can't I just ignore them and hope they go away?


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

Re: Simple question

[Kushal Kumaran]

On April 16, 2014 12:37:53 AM GMT+05:30, Chris Angelico  
wrote:
>On Wed, Apr 16, 2014 at 5:02 AM, Phil Dobbin 
>wrote:
>> On 15/04/2014 19:41, Chris Angelico wrote:
>>
>>> Recommendation: If you don't understand something, keep it there :)
>>> You can just copy and paste from the Python interactive interpreter
>>> (command line or IDLE) straight into the email; it'll be easier to
>>> explain, that way.
>>>
>>> This is *especially* true of tracebacks. You might not see the
>>> difference, but to us, it's often hugely helpful to see the entire
>>> exception report.
>>
>> Good advice.
>>
>> Truth is I'm writing emails on my laptop & attempting Python on a
>> Desktop machine so I lazily copied by eye. My mistake.
>
>Understandable. I currently am using two consoles (laptop at my right
>hand, desktop in front of me), and every now and then I want to copy
>and paste across them :) I mean, shared clipboard works just fine
>across all my VM guests (and as I type that, Disney's cast is singing
>"Be our guest" in my background music), it even works across remote
>desktop, but for some reason, swinging my hands 90 degrees doesn't
>transfer the clipboard. This strikes me as a major flaw in human
>beings.
>

You want synergy. http://synergy-foss.org/


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: random.seed question (not reproducing same sequence)

[John Gordon]

In  Nick Mellor 
 writes:

> In response to your question, John, all I know is that my own code doesn't
> use the random module outside of this code fragment.

Does addUpdate_special_to_cart() use any random methods?

In any case, a further test would be to strip out all the business logic
and leave only the calls to random, and see if the results still differ.

Something like this:

rnd = random.Random()
for qty in [4, 0]:
print "qty is %s" % qty
rnd.seed(seed)
print "seed is %s" % seed
for cart in range(test_size):
print "cart is %s " % cart
for special in range(rnd.randrange(3)):
print "special is %s " % special
print "stockbin is %s" % rnd.randrange(test_size)
print "special_id is %s" % rnd.randrange(test_size)
print "products is %s" % [(rnd.choice(PRODUCTS), 
rnd.choice(range(10))) for r in range(rnd.randrange(7))])

Run that code sample and see if the results differ when qty is 4 vs 0.

-- 
John Gordon Imagine what it must be like for a real medical doctor to
gor...@panix.comwatch 'House', or a real serial killer to watch 'Dexter'.

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

Re: Simple question

[Chris Angelico]

On Wed, Apr 16, 2014 at 1:19 PM, Kushal Kumaran
 wrote:
>>Understandable. I currently am using two consoles (laptop at my right
>>hand, desktop in front of me), and every now and then I want to copy
>>and paste across them :) I mean, shared clipboard works just fine
>>across all my VM guests (and as I type that, Disney's cast is singing
>>"Be our guest" in my background music), it even works across remote
>>desktop, but for some reason, swinging my hands 90 degrees doesn't
>>transfer the clipboard. This strikes me as a major flaw in human
>>beings.
>>
>
> You want synergy. http://synergy-foss.org/

Usually I want separate keyboard and mouse, so that I can be playing
Command & Conquer Renegade on one system while responding to emails on
the other (hold W so Havoc keeps walking, read through emails by
scrolling with right hand...); it's just the clipboard. It would, of
course, be possible to write a clipboard viewer program for whichever
platform - say, OS/2 - and have it connect via a TCP/IP socket to a
program on another system - say, a Linux box - that has a little
hidden window and puts stuff onto the clipboard. I will neither
confirm nor deny having actually done this...

*twiddles thumbs*

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

Re: Martijn Faassen: The Call of Python 2.8

[Chris Angelico]

On Wed, Apr 16, 2014 at 12:51 PM, Steven D'Aprano
 wrote:
> Converting "print spam" to "print(spam)" is the trivial part of it. The
> biggest change between Python 2.x and 3.x is the bytes to Unicode shift,
> and that is *not trivial*. Python 2.x tries very hard to make bytes and
> strings interoperate even when doing so is the wrong thing to do. So
> there is a lot of Python 2 code that is *broken* with respect to strings,
> but *seems okay* so long as you only test it using pure ASCII. Python 3
> no longer tries to hide the difference, it forces you to confront the
> fact that bytes and strings are not the same. To people raised on ASCII-
> only programming standards, that's a huge paradigm shift, and a confusing
> one. There's a lot to learn, a lot of pain if you don't learn it, and
> there can be a lot of effort needed to migrate string code to Python 3.

Has anyone ever had the same "oh great, now I have to push everyone
through a paradigm shift" feeling about anything else? The only one I
can think of is shifting my whole family off Windows file sharing
(just accessing files everywhere) onto wholesale use of source control
(have a local copy, and push your changes).

> (Depending on what your code actually does. It is remarkable just how
> much string code you can write that works identically in 2.x and 3.x.
> Basic string handling remains basic in both.)

With PEP 461 (slated for 3.5), that's going to get even easier. Not
only will a simple double-quoted string "do the right thing" on both
platforms, but both b"binary" and u"unicode" will support the same
percent-formatting as well. But you do have to limit your definition
of "2.x"; a lot of that commonality is the result of deliberate
design, and NOT just "oh hey look it works", which means that 2.4 and
3.4 are very different. I respect and do not envy those who have to
support both RHEL and Arch...

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

Re: Martijn Faassen: The Call of Python 2.8

[Chris Angelico]

On Wed, Apr 16, 2014 at 12:52 PM, Steven D'Aprano
 wrote:
> I'm actually asking a serious question. How does a distro "actively hide"
> something publicly available on the Internet? Note that, on Linux (when
> you talk about "distributions", you probably don't mean OS X or Windows)
> all the compiler tools needed to install from source are readily
> available, so anyone who wants to install a Python version not supported
> by their distro can do so. Many people don't wish to install anything
> outside of their distro's supported packages, but that's their choice,
> not the distro imposing anything on them.

I'd say it's not so much "actively hide" as just "abandon people to
their own devices". It's all very well to say "well hey, just go and
compile it from source"; this assumes two things:

1) The available source code will compile on your platform
2) The user knows how to compile code.

The first is true of the platforms supported by python.org, but that's
not the OS/distribution helping you to get Python - that's Python
helping you to get Python. The second... that's where things like
"apt-get build-dep" come in, but mainly there's a general
understanding among end users that compiling code is haaard. Some
cultures have this more strongly than others... sometimes for good
reason. (I had stupid amounts of trouble trying to get a C compiler
going on OS X. A non-programmer, doing the same job, might well give
up, and I wouldn't argue.) Compiling from source without a package
manager fetching all the appropriate libraries means an iterative
process of "compile or build, see what the error is, figure out what's
missing, fetch it, GOTO 10". For me, that's life; that's something
I've done on a number of different systems, and I know lots of the
clues and/or the tools for figuring things out. For many
non-programmers, though, if there's no binary package, they won't use
the software.

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

Re: Martijn Faassen: The Call of Python 2.8

[wxjmfauth]

It is more than clear to me, Python did and does not
understand the "unicode case".

jmf
-- 
https://mail.python.org/mailman/listinfo/python-list