Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
Nick Coghlan wrote: I think it more comes from the n-dimensional array approach - 'n=0' is then a natural issue to consider. But only if it makes sense. I still think there are some severe conceptual difficulties with 0D arrays. One is the question of how many items it contains. With 1 or more dimensions, you can talk about its size along any chosen dimension. But with 0 dimensions there's no size to measure. Who's to say a 0D array has a size of 1, then? Part of my brain keeps saying it should be 0 -- i.e. it contains nothing at all! Also, what kind of thing does a[] yield? Do we finally, at last, get an actual scalar, or do we get a -1 dimensional array? :-) I'm having trouble seeing a real use for a 0D array as something distinct from a scalar, as opposed to them just being an oddity that happens to arise as a side effect of the way Numeric/Numpy are implemented. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
Greg Ewing wrote: I'm having trouble seeing a real use for a 0D array as something distinct from a scalar, as opposed to them just being an oddity that happens to arise as a side effect of the way Numeric/Numpy are implemented. This has been rehashed over and over again on numpy-discussion. The upshot is that numpy no longer creates rank-zero arrays unless if the user really asks for one. The remaining use cases are documented here: http://projects.scipy.org/scipy/numpy/wiki/ZeroRankArray -- 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UUID module
Fredrik Lundh wrote: Ka-Ping Yee wrote: Quite a few people have expressed interest in having UUID functionality in the standard library, and previously on this list some suggested possibly using the uuid.py module i wrote: http://zesty.ca/python/uuid.py +1! +1 as well. I have a couple of suggestions for improving that implementation: 1. You're currently using os.urandom, which can raise a NotImplementedError. You should be prepared to fall back on a different PRNG... which leads to the 2nd suggestion: 2. random.randrange is a method on a default random.Random instance that, although seeded by urandom (if available), may not be the user's preferred PRNG. I recommend making it possible for the user to supply their own random.Random instance for use by the module. That's all. :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
On Sat, 10 Jun 2006, Greg Ewing wrote: I'm having trouble seeing a real use for a 0D array as something distinct from a scalar, as opposed to them just being an oddity that happens to arise as a side effect of the way Numeric/Numpy are implemented. I think the whole discussion about the concept and meaning of zero-dimensional arrays is mostly irrelevant to the original issue. The original issue is a *syntax* question: should x[()] be written as x[]? And from a syntax perspective, it's a bad idea. x[] is much more often a typo than an intentional attempt to index a zero-dimensional array. The compiler should continue to treat it as a syntax error. -- ?!ng ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
Ka-Ping Yee wrote: And from a syntax perspective, it's a bad idea. x[] is much more often a typo than an intentional attempt to index a zero-dimensional array. but how often is it a typo? for example, judging from c.l.python traffic, forgetting to add a return statement is a quite common, but I haven't seen anyone arguing that we deprecate the implied return None behaviour. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
Ka-Ping Yee wrote: I think the whole discussion about the concept and meaning of zero-dimensional arrays is mostly irrelevant to the original issue. The original issue is a *syntax* question: should x[()] be written as x[]? But, at least as presented in the PEP, it's a syntax that was motivated by a perceived need for dealing with 0D arrays. So it seems relevant to ask whether 0D arrays are really needed or not. Does anyone have any other use case for this syntax? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] beta1 coming real soon
Neal Norwitz wrote: It's June 9 in most parts of the world. The schedule calls for beta 1 on June 14. That means there's less than 4 days until the expected code freeze. Please don't rush to get everything in at the last minute. The buildbots should remain green to keep Anthony happy and me sane (or is it the other way around). If you plan to make a checkin adding a feature (even a simple one), you oughta let people know by responding to this message. Please get the bug fixes in ASAP. Remember to add tests! I still harbour hopes of sorting SF1454481 out in time; if I have it sorted out by 1200UTC (2200AEST) on June 13, I'll merge it from the branch I created for it. sorted out includes addressing the issues Tim, Skip yourself raised. Regards, Andrew. -- - Andrew I MacIntyre These thoughts are mine alone... E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370 [EMAIL PROTECTED] (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UUID module
Okay. I have done as Fredrik suggested: 6. Combine 2 and 3: require the user to pass in a MAC argument to uuid1, but provide a SlowGetMacAddress helper that wraps the existing code. I agree with Thomas Wouters: That sounds like the right thing to do, although I wouldn't call it slow; just let it be documented as 'might not always work and might be inefficient', The method for getting the node ID is called getnode() and is documented as possibly slow. If a hardware address cannot be obtained, we use a random 48-bit number with the highest bit set to 1, as recommended by RFC 4122. I have done as Skip proposed here: Or make the MAC address an optional arg to uuid1. If given, use it. If not, use the slow lookup (then cache the result). I've made the address an optional argument, not a required one, because i think Explicit better than implicit applies to changes in output. It makes sense to require an explicit argument if it's actually going to produce a different result, but i don't think it is necessary to require an explicit argument just because the routine might be a bit slow. Letting the address be an optional argument means that in future, we can change the implementation of getnode() to make it faster or more reliable, and users of the module will benefit without having to change any of their code. Finally, Phillip brought up PEAK: PEAK's uuid module does this such that if win32all is present, you get a Windows GUID, or if you have a FreeBSD 5+ or NetBSD 2+ kernel you use the local platform uuidgen API. See e.g.: ...so i looked at PEAK's getnodeid48() routine and borrowed the Win32 calls from there, with a comment giving attribution to PEAK. Oh, and there is now a test suite that should cover all the code paths. This is all posted at http://zesty.ca/python/uuid.py now, documentation page at http://zesty.ca/python/uuid.html, tests at http://zesty.ca/python/test_uuid.py . I'll sleep now (6 am), commit tomorrow unless there are objections. Thanks for your input, everyone! -- ?!ng ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UUID module
On Sat, 10 Jun 2006, Mike Brown wrote: I have a couple of suggestions for improving that implementation: 1. You're currently using os.urandom, which can raise a NotImplementedError. You should be prepared to fall back on a different PRNG... The latest version (http://zesty.ca/python/uuid.py) does this. 2. random.randrange is a method on a default random.Random instance that, although seeded by urandom (if available), may not be the user's preferred PRNG. I recommend making it possible for the user to supply their own random.Random instance for use by the module. I decided not to add more code to do this, because the UUID constructor is now designed in such a way that it's very simple to convert your own randomness into a UUID. If you want to use another source of randomness, you'd just get 16 random bytes and then call UUID(bytes=random_stuff, version=4). That seems simpler to me than adding an extra argument and requiring a randrange() method on it. -- ?!ng ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] beta1 coming real soon
On Thu, 8 Jun 2006, Neal Norwitz wrote: If you plan to make a checkin adding a feature (even a simple one), you oughta let people know by responding to this message. Please get the bug fixes in ASAP. Remember to add tests! Just to make this appear on this thread: i'm planning to check in the uuid.py module at http://zesty.ca/python/uuid.py (with tests). -- ?!ng ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
Greg Ewing wrote: Ka-Ping Yee wrote: I think the whole discussion about the concept and meaning of zero-dimensional arrays is mostly irrelevant to the original issue. The original issue is a *syntax* question: should x[()] be written as x[]? But, at least as presented in the PEP, it's a syntax that was motivated by a perceived need for dealing with 0D arrays. So it seems relevant to ask whether 0D arrays are really needed or not. Does anyone have any other use case for this syntax? I believe the NumPy link Robert posted does a pretty good job of thrashing out the use cases (or lack thereof). I also thought a bit more about the places where the comma separator is used as part of the syntax, and realised that there is no consistent behaviour used when the expression is omitted entirely. In return and yield, omitting the expression is equivalent to using 'None' In print, omitting the expression is equivalent to using the empty string. In raise, omitting the expression has no real equivalent short of: exctype, excval, exctb = sys.exc_info() raise exctype, excval, exctb In an except clause, omitting the expression means the clause handles all exceptions. In a function definition, omitting the expression means the function accepts no arguments. In a function call, omitting the expression is equivalent to writing *(). Most other places (assignment statements, for loops, etc) omitting the expression that may contain a comma separator is simply not permitted. The closest parallel would be with return/yield, as those actually create real tuples the same way subscripts do, and allow the expression to be omitted entirely. By that parallel, however, an implicit subscript (if adopted) should be None rather than (). Adapting the table from the pre-PEP to describe return statements (and yield expressions): return i, j, k -- return (i, j, k) return i, j -- return (i, j) return i, -- return (i, ) return i-- return (i) return ()# (No implicit equivalent) return -- return None With the status quo, however, subscripts are simply equivalent to the RHS of an assignment statement in *requiring* that the expression be non-empty: x = i, j, k -- x = (i, j, k) x = i, j -- x = (i, j) x = i, -- x = (i, ) x = i-- x = (i) x = () # (No implicit equivalent) x = None # (No implicit equivalent) The PEP doesn't make a sufficiently compelling case for introducing yet-another-variant on the implicit behaviour invoked when a particular subexpression is missing from a construct. I guess I could have gone with my initial instinct of -1 and saved myself some mental exercise ;) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UUID module
On 6/10/06, Ka-Ping Yee [EMAIL PROTECTED] wrote: ...so i looked at PEAK's getnodeid48() routine and borrowed the Win32 calls from there, with a comment giving attribution to PEAK. Instead of using pywin32, could you use ctypes, as that's part of core Python? It looks like the only Win32 API you use is CoCreateGUID, so wrapping it should be doable... Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] beta1 coming real soon
Ka-Ping Yee wrote: On Thu, 8 Jun 2006, Neal Norwitz wrote: If you plan to make a checkin adding a feature (even a simple one), you oughta let people know by responding to this message. Please get the bug fixes in ASAP. Remember to add tests! Just to make this appear on this thread: i'm planning to check in the uuid.py module at http://zesty.ca/python/uuid.py (with tests). Just a quick comment, ipconfig is localized on my system so it'll output something like this: endereço inet6: fe80::20e:a6ff:feac:c3bd/64 Escopo:Link So it needs to be run with LANG set to C to avoid this. Perhaps it would be better to use the same API ipconfig uses, but it's highly platform specific of course. Johan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UUID module
Ka-Ping Yee wrote:
Finally, Phillip brought up PEAK:
PEAK's uuid module does this such that if win32all is present,
you get a Windows GUID, or if you have a FreeBSD 5+ or
NetBSD 2+ kernel you use the local platform uuidgen API. See e.g.:
...so i looked at PEAK's getnodeid48() routine and borrowed the
Win32 calls from there, with a comment giving attribution to PEAK.
Oh, and there is now a test suite that should cover all the code paths.
This is all posted at http://zesty.ca/python/uuid.py now,
documentation page at http://zesty.ca/python/uuid.html,
tests at http://zesty.ca/python/test_uuid.py .
(From http://zesty.ca/python/uuid.py:)
def win32_getnode():
Get the hardware address on Windows using Win32 extensions.
try:
import pywintypes
return int(pywintypes.CreateGuid()[-13:-1], 16)
except:
pass
try:
import pythoncom
return int(pythoncom.CreateGuid()[-13:-1], 16)
except:
pass
This does not work, for several reasons.
1. (pythoncom|pywintypes).CreateGuid() return a PyIID instance, which you
cannot slice:
import pywintypes
pywintypes.CreateGuid()
IID('{4589E547-4CB5-4BCC-A7C3-6E88FAFB4301}')
type(pywintypes.CreateGuid())
type 'PyIID'
pywintypes.CreateGuid()[-13:-1]
Traceback (most recent call last):
File stdin, line 1, in ?
TypeError: unsubscriptable object
So, you would have to change your code to 'str(pythoncom.CreateGuid())[-13:-1]'.
(BTW: Why does it first try pywintypes, the pythoncom?)
2. These functions call to win32 CoCreateGuid function, which create a new uuid.
As documented on MSDN, this calls the UuidCreate function which:
The UuidCreate function generates a UUID that cannot be traced to the
ethernet/token ring
address of the computer on which it was generated.
In other words, the last 12 characters do *not* identify the mac address, in
fact your function,
if repaired, returns a different result each time it is called. See this link
for
further info:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rpc/rpc/uuidcreate.asp
A possible solution, if you really need the mac address, is to call the
UuidCreateSequential
function where available (W2k, XP, ...), and UuidCreate on older systems (W98,
ME).
Link to MSDN:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rpc/rpc/uuidcreatesequential.asp
3. Now that ctypes is part of Python, why not use it? This snippet of code
displays the mac address of one of the ethernet adapters I have in my machine:
from ctypes import *
import binascii
class UUID(Structure):
_fields_ = [(Data1, c_ulong),
(Data1, c_ushort),
(Data1, c_ushort),
(Data1, c_ubyte * 8)]
def CreateGuid():
uuid = UUID()
if 0 == windll.rpcrt4.UuidCreateSequential(byref(uuid)):
return str(buffer(uuid))
print binascii.hexlify(CreateGuid()[-6:])
It should be extended to also work on w98 or me, probably.
Thomas
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UUID module
On 6/10/06, Paul Moore [EMAIL PROTECTED] wrote: On 6/10/06, Ka-Ping Yee [EMAIL PROTECTED] wrote: ...so i looked at PEAK's getnodeid48() routine and borrowed the Win32 calls from there, with a comment giving attribution to PEAK. Instead of using pywin32, could you use ctypes, as that's part of core Python? It looks like the only Win32 API you use is CoCreateGUID, so wrapping it should be doable... Here's some sample code (taken from Thomas Heller's comtypes module) from ctypes import oledll, Structure, byref from ctypes.wintypes import BYTE, WORD, DWORD class GUID(Structure): ... _fields_ = [(Data1, DWORD), ... (Data2, WORD), ... (Data3, WORD), ... (Data4, BYTE * 8)] ... guid = GUID() oledll.ole32.CoCreateGuid(byref(guid)) 0 guid __main__.GUID object at 0x00978EE0 guid.Data1 3391869098L guid.Data2 51115 guid.Data3 20060 guid.Data4 __main__.c_byte_Array_8 object at 0x00978E40 I'm not sure what the int(...[-13,-1], 16) does (as it stands, it fails for me - I think you need to put str() round the CreateGuid call) but I *think* it's the equivalent of guid.Data1 above. So, you'd have: def win32_getnode(): Get the hardware address on Windows using Win32 extensions. from ctypes import oledll, Structure, byref from ctypes.wintypes import BYTE, WORD, DWORD class GUID(Structure): _fields_ = [(Data1, DWORD), (Data2, WORD), (Data3, WORD), (Data4, BYTE * 8)] guid = GUID() oledll.ole32.CoCreateGuid(byref(guid)) return guid.Data1 Hope this is of use. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UUID module
Hi Thomas, This does not work, for several reasons. 1. (pythoncom|pywintypes).CreateGuid() return a PyIID instance, which you cannot slice: You're right. The PEAK code must have been based on an earlier version of the CreateGuid() routine. I've fixed this, and added detection of the UUID version so that the MAC address will only be picked up if the UUID version is 1. (BTW: Why does it first try pywintypes, the pythoncom?) Because PEAK does this, and i see the CreateGuid routine imported from both modules in Google searches for code, i assumed that it used to live in one module and moved to the other. I've also figured out how to get the MAC address using NetBIOS calls, and added that to the repertoire of methods. I've tested this and it works fast. I think this may be better than UuidCreateSequential, because it should work on both Win98 and XP. The updated version is posted at http://zesty.ca/python/uuid.py . -- ?!ng ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UUID module
Ka-Ping Yee wrote: Hi Thomas, This does not work, for several reasons. 1. (pythoncom|pywintypes).CreateGuid() return a PyIID instance, which you cannot slice: You're right. The PEAK code must have been based on an earlier version of the CreateGuid() routine. I've fixed this, and added detection of the UUID version so that the MAC address will only be picked up if the UUID version is 1. (BTW: Why does it first try pywintypes, the pythoncom?) Because PEAK does this, and i see the CreateGuid routine imported from both modules in Google searches for code, i assumed that it used to live in one module and moved to the other. I've also figured out how to get the MAC address using NetBIOS calls, and added that to the repertoire of methods. I've tested this and it works fast. I think this may be better than UuidCreateSequential, because it should work on both Win98 and XP. I have not tested the speed, but extending my snippet to also work on 98 should be nearly trivial: try: _func = windll.rpcrt4.UuidCreateSequential except AttributeError: _func = windll.rpcrt4.UuidCreate def CreateGuid(): uuid = UUID() if 0 == _func(byref(uuid)): return str(buffer(uuid)) Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] beta1 coming real soon
On 6/10/06, Johan Dahlin [EMAIL PROTECTED] wrote: Ka-Ping Yee wrote: On Thu, 8 Jun 2006, Neal Norwitz wrote: If you plan to make a checkin adding a feature (even a simple one), you oughta let people know by responding to this message. Please get the bug fixes in ASAP. Remember to add tests! Just to make this appear on this thread: i'm planning to check in the uuid.py module at http://zesty.ca/python/uuid.py (with tests). Just a quick comment, ipconfig is localized on my system so it'll output something like this: endereço inet6: fe80::20e:a6ff:feac:c3bd/64 Escopo:Link So it needs to be run with LANG set to C to avoid this. Actually, the code uses ifconfig, which doesn't exist on Windows. You want the command ipconfig /all. And it assumes Windows is installed on the C: drive (normal, but not guaranteed). Perhaps it would be better to use the same API ipconfig uses, but it's highly platform specific of course. Here's a VB script that gets all the MAC addresses on the system using WMI: Dim objNetworkAdapters, objAdapter, objWMI Set objWMI = Nothing Set objWMI = GetObject(winmgmts:) ' Get a list of IP-enabled adapters. Set objNetworkAdapters = objWMI.ExecQuery(select * from Win32_NetworkAdapterConfiguration where IPEnabled = 1) For Each objAdapter In objNetworkAdapters wscript.echo Network adapter: objAdapter.Caption has MAC address objAdapter.MacAddress Next It might be worth noting that on my PC, this gets one real network adapter, and two VMWare virtual adapter. Whether this affects things, I don't know. This script and ipconfig /all give the adapters in different orders. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UUID module
On Sat, 10 Jun 2006, Thomas Heller wrote: I have not tested the speed, but extending my snippet to also work on 98 should be nearly trivial: try: _func = windll.rpcrt4.UuidCreateSequential except AttributeError: _func = windll.rpcrt4.UuidCreate def CreateGuid(): uuid = UUID() if 0 == _func(byref(uuid)): return str(buffer(uuid)) Okay. Thanks for this. I'll give it a shot. -- ?!ng ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] beta1 coming real soon
On Sat, 10 Jun 2006, Paul Moore wrote: Actually, the code uses ifconfig, which doesn't exist on Windows. You want the command ipconfig /all. I fixed that before you posted this message. :) -- ?!ng ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] beta1 coming real soon
On 6/10/06, Ka-Ping Yee [EMAIL PROTECTED] wrote: On Sat, 10 Jun 2006, Paul Moore wrote: Actually, the code uses ifconfig, which doesn't exist on Windows. You want the command ipconfig /all. I fixed that before you posted this message. :) Give Guido the time machine keys back! :-) Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] beta1 coming real soon
On 9-jun-2006, at 20:22, Martin v. Löwis wrote: Ronald Oussoren wrote: How hard is the feature freeze? Would it be possible to update the Carbon bindings after beta1? Given Apple's focus on backward compatibility the update should only add new functionality, not remove existing functions/types. I'd say it's absolute wrt. to requiring permission from the release manager. I suppose that's as good as it gets, and that's fine by me. The reason I asked is that if the anwer would be no way I definitely wouldn't bother to spent time on this. The point of not allowing new features after a beta release is that one wants to avoid getting untested new features into a release. For that goal, it is not that relevant whether the new features are guaranteed not to break any existing features - they still don't get the testing that the beta releases try to achieve. If the past is any prediction of the future beta releases won't result in enough testing of the Carbon wrappers :-/. AFAIK there are known issues with at least some of the wrappers but sadly enough those issues are not on the tracker. I know of problems with OSA support because an external package that uses those extensions has basicly forked them to be able to apply bugfixes. I've just sent a message to the pythonmac-sig to ask people to file bugreports about problems they'd like to see fixed. Hopefully Python 2.5 will see more testing on the mac because there will be prompt binary releases of the betas this time around. Ronald ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UUID module
Phillip J. Eby wrote: At 08:22 AM 6/10/2006 -0500, Ka-Ping Yee wrote: Finally, Phillip brought up PEAK: PEAK's uuid module does this such that if win32all is present, you get a Windows GUID, or if you have a FreeBSD 5+ or NetBSD 2+ kernel you use the local platform uuidgen API. See e.g.: ...so i looked at PEAK's getnodeid48() routine and borrowed the Win32 calls from there, with a comment giving attribution to PEAK. There appears to be a transcription error, there; the second win32 import isn't covered by a try/except and the ImportError seems to have disappeared as well. Also, for Python 2.5, these imports could probably be replaced with a ctypes call, though I'm not experienced enough w/ctypes to figure out what the call should be. Similarly, for the _uuidgen module, you've not included the C source for that module or the setup.py incantations to build it. But again, it could probably be replaced by ctypes calls to uuidgen(2) on BSD-ish platforms. I'll take a whack at addressing these once the code is in, though, unless there's a ctypes guru or two available...? I don't know if this is the uuidgen you're talking about, but on linux there is libuuid: from ctypes import * lib = CDLL(libuuid.so.1) uuid = create_string_buffer(16) lib.uuid_generate(byref(uuid)) 2131088494 from binascii import hexlify hexlify(buffer(uuid)) '0c77b6d7e5f940b18e29a749057f6ed4' ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UUID module
At 11:16 AM 6/10/2006 -0500, Ka-Ping Yee wrote: On Sat, 10 Jun 2006, Thomas Heller wrote: [some nice ctypes code] Done. Works like a charm. Thanks for providing the code! On Sat, 10 Jun 2006, Phillip J. Eby wrote: Also, for Python 2.5, these imports could probably be replaced with a ctypes call, though I'm not experienced enough w/ctypes to figure out what the call should be. Happily, we have *the* ctypes guru here, and he's solved the problem for Windows at least. Similarly, for the _uuidgen module, you've not included the C source for that module or the setup.py incantations to build it. Yes, the idea was that even though _uuidgen isn't included with core Python, users would magically benefit if they installed it (or if they happen to be using Python in a distribution that includes it); _uuidgen is actually peak.util._uuidgen; as far as I know, that's the only place you can get it. it's the same idea with the stuff that refers to Win32 extensions. Is the presence of _uuidgen sufficiently rare that i should leave out uuidgen_getnode() for now, then? Either that, or we could add the code in to build it. PEAK's setup.py does some relatively simple platform checks to determine whether you're on a BSD that has it. The other alternative is to ask the guru nicely if he'll provide another ctypes snippet to call the uuidgen(2) system call if present. :) By the way, I'd love to see a uuid.uuid() constructor that simply calls the platform-specific default UUID constructor (CoCreateGuid or uuidgen(2)), if available, before falling back to one of the Python implementations. Most of my UUID-using application code doesn't really care what type of UUID it gets, and if the platform has an efficient mechanism, it'd be convenient to use it. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
Hello, I'll try to answer the questions in one message. Sorry for not being able to do it until now. About the joke - it isn't, I really need it. About the timing - Of course, I can live with this getting into 2.6, and I think that I may even be able to stay alive if this were rejected. I still personally think that if people agree that it's a good idea it might get in, since there's almost nothing to be decided except for that - but of course, I can understand not wanting to rush things too much. About whether NumPy should return real scalars or 0-dimensional arrays - I don't know. About the use case - I think that's the real thing I didn't explain well and needs explanation, so I will try to do it better this time. I'm talking about something similar to a spreadsheet in that it saves data, calculation results, and the way to produce the results. However, it is not similar to a spreadsheet in that the data isn't saved in an infinite two-dimensional array with numerical indices. Instead, the data is saved in a few tables, each storing a different kind of data. The tables may be with any desired number of dimensions, and are indexed by meaningful indices, instead of by natural numbers. For example, you may have a table called sales_data. It will store the sales data in years from set([2003, 2004, 2005]), for car models from set(['Subaru', 'Toyota', 'Ford']), for cities from set(['Jerusalem', 'Tel Aviv', 'Haifa']). To refer to the sales of Ford in Haifa in 2004, you will simply write: sales_data[2004, 'Ford', 'Haifa']. If the table is a source of data (that is, not calculated), you will be able to set values by writing: sales_data[2004, 'Ford', 'Haifa'] = 1500. Tables may be computed tables. For example, you may have a table which holds for each year the total sales in that year, with the income tax subtracted. It may be defined by a function like this: lambda year: sum(sales_data[year, model, city] for model in models for city in cities) / (1 + income_tax_rate) Now, like in a spreadsheet, the function is kept, so that if you change the data, the result will be automatically recalculated. So, if you discovered a mistake in your data, you will be able to write: sales_data[2004, 'Ford', 'Haifa'] = 2000 and total_sales[2004] will be automatically recalculated. Now, note that the total_sales table depends also on the income_tax_rate. This is a variable, just like sales_data. Unlike sales_data, it's a single value. We should be able to change it, with the result of all the cells of the total_sales table recalculated. But how will we do it? We can write income_tax_rate = 0.18 but it will have a completely different meaning. The way to make the income_tax_rate changeable is to think of it as a 0-dimensional table. It makes sense: sales_data depends on 3 parameters (year, model, city), total_sales depends on 1 parameter (year), and income_tax_rate depends on 0 parameters. That's the only difference. So, thinking of it like this, we will simply write: income_tax_rate[] = 0.18 Now the system can know that the income tax rate has changed, and recalculate what's needed. We will also have to change the previous function a tiny bit, to: lambda year: sum(sales_data[year, model, city] for model in models for city in cities) / (1 + income_tax_rate[]) But it's fine - it just makes it clearer that income_tax_rate[] is a part of the model that may change its value. I hope that I managed to explain the use case better this time - please ask if my description isn't clear enough. Thanks for your comments, please send more, Noam ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] a note in random.shuffle.__doc__ ...
...claims: Note that for even rather small len(x), the total number of permutations of x is larger than the period of most random number generators; this implies that most permutations of a long sequence can never be generated. Now -- why would the behavior of most random number generators be relevant here? The module's docs claim, for its specific Mersenne Twister generator, a period of 2**19997-1, which is (e.g.) a comfortable 130128673800676351960752618754658780303412233749552410245124492452914636 028095467780746435724876612802011164778042889281426609505759158196749438 742986040468247017174321241233929215223326801091468184945617565998894057 859403269022650639413550466514556014961826309062543 times larger than the number of permutations of 2000 items, which doesn't really feel to me like a rather small len(x) in this context (what I'm most often shuffling is just a pack of cards -- len(x)==52 -- for example). I suspect that the note is just a fossil from a time when the default random number generator was Whichman-Hill, with a much shorter period. Should this note just be removed, or instead somehow reworded to point out that this is not in fact a problem for the module's current default random number generator? Opinions welcome! Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 issues need resolving in a few days
On Saturday 10 June 2006 12:34, Fredrik Lundh wrote: if all undocumented modules had as much documentation and articles as ET, the world would be a lot better documented ;-) I've posted a text version of the xml.etree.ElementTree PythonDoc here: Here's a question that we should answer before the beta: With the introduction of the xmlcore package in Python 2.5, should we document xml.etree or xmlcore.etree? If someone installs PyXML with Python 2.5, I don't think they're going to get xml.etree, which will be really confusing. We can be sure that xmlcore.etree will be there. I'd rather not propogate the pain caused xml package insanity any further. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
Hello, 2006/6/10, Nick Coghlan [EMAIL PROTECTED]: The closest parallel would be with return/yield, as those actually create real tuples the same way subscripts do, and allow the expression to be omitted entirely. By that parallel, however, an implicit subscript (if adopted) should be None rather than (). Adapting the table from the pre-PEP to describe return statements (and yield expressions): return i, j, k -- return (i, j, k) return i, j -- return (i, j) return i, -- return (i, ) return i-- return (i) return ()# (No implicit equivalent) return -- return None With the status quo, however, subscripts are simply equivalent to the RHS of an assignment statement in *requiring* that the expression be non-empty: x = i, j, k -- x = (i, j, k) x = i, j -- x = (i, j) x = i, -- x = (i, ) x = i-- x = (i) x = () # (No implicit equivalent) x = None # (No implicit equivalent) The PEP doesn't make a sufficiently compelling case for introducing yet-another-variant on the implicit behaviour invoked when a particular subexpression is missing from a construct. I hope that my (hopefully) better explanation made the use case more compelling, but I want to add two points in favour of an empty tuple: 1. If you want, you can ignore the x[(i, j, k)] equivalence completely, since it doesn't work all the times - for example, you can write x[1:2, 3:4], but you can't write x[(1:2, 3:4)]. You can think of x[i, j, k] as a syntax for specifying a cell in a 3-dimensional array, resulting in a call to x.__getitem__ with a 3-tuple describing the subscript for each dimension. In that view, x[], which is a syntax for specifying the cell of a 0-dimensional, should result in a __getitem__ call with an empty tuple, as there are no subscripts to be described. 2. My equivalencies are better than yours :-), since they are dealing with equivalencies for this specific syntax, while yours are dealing with similar properies of a syntax for doing something completely different. I guess I could have gone with my initial instinct of -1 and saved myself some mental exercise ;) Why? Mental exercise is a good way to keep you mental ;) Noam ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FYI: wsgiref is now checked in
Just noticed that, at least on Windows, test_wsgiref fails when Python
is run with -O (but passes without -O):
$ python -O -E -tt ../Lib/test/regrtest.py -v test_wsgiref
test_wsgiref
testAbstractMethods (test.test_wsgiref.HandlerTests) ... ok
testBasicErrorOutput (test.test_wsgiref.HandlerTests) ... ok
testCGIEnviron (test.test_wsgiref.HandlerTests) ... ok
testContentLength (test.test_wsgiref.HandlerTests) ... ok
testEnviron (test.test_wsgiref.HandlerTests) ... ok
testErrorAfterOutput (test.test_wsgiref.HandlerTests) ... ok
testHeaderFormats (test.test_wsgiref.HandlerTests) ... ok
testScheme (test.test_wsgiref.HandlerTests) ... ok
testExtras (test.test_wsgiref.HeaderTests) ... ok
testMappingInterface (test.test_wsgiref.HeaderTests) ... ok
testRequireList (test.test_wsgiref.HeaderTests) ... ok
test_plain_hello (test.test_wsgiref.IntegrationTests) ... ok
test_simple_validation_error (test.test_wsgiref.IntegrationTests) ... FAIL
test_validated_hello (test.test_wsgiref.IntegrationTests) ... ok
testAppURIs (test.test_wsgiref.UtilityTests) ... ok
testCrossDefaults (test.test_wsgiref.UtilityTests) ... ok
testDefaults (test.test_wsgiref.UtilityTests) ... ok
testFileWrapper (test.test_wsgiref.UtilityTests) ... FAIL
testGuessScheme (test.test_wsgiref.UtilityTests) ... ok
testHopByHop (test.test_wsgiref.UtilityTests) ... ok
testNormalizedShifts (test.test_wsgiref.UtilityTests) ... ok
testReqURIs (test.test_wsgiref.UtilityTests) ... ok
testSimpleShifts (test.test_wsgiref.UtilityTests) ... ok
==
FAIL: test_simple_validation_error (test.test_wsgiref.IntegrationTests)
--
Traceback (most recent call last):
File C:\Code\python\lib\test\test_wsgiref.py, line 156, in
test_simple_validation_error
AssertionError: Headers (('Content-Type', 'text/plain')) must
AssertionError: 'ValueError: too many values to unpack' !=
AssertionError: Headers (('Content-Type', 'text/plain')) mus
t be of type list: type 'tuple'
==
FAIL: testFileWrapper (test.test_wsgiref.UtilityTests)
--
Traceback (most recent call last):
File C:\Code\python\lib\test\test_wsgiref.py, line 312, in testFileWrapper
self.checkFW(xyz*50, 120, [xyz*40,xyz*10])
File C:\Code\python\lib\test\test_wsgiref.py, line 211, in checkFW
compare_generic_iter(make_it,match)
File C:\Code\python\lib\test\test_wsgiref.py, line 100, in
compare_generic_iter
raise AssertionError(Too many items from __getitem__,it)
AssertionError: ('Too many items from __getitem__',
wsgiref.util.FileWrapper instance at 0x00B432D8)
--
Ran 23 tests in 0.046s
FAILED (failures=2)
test test_wsgiref failed -- errors occurred; run in verbose mode for details
1 test failed:
test_wsgiref
This may be because compare_generic_iter() uses `assert` statements,
and those vanish under -O. If so, a test shouldn't normally use
`assert`. On rare occasions it's appropriate, like test_struct's:
if x 0:
expected += 1L self.bitsize
assert expected 0
That isn't testing any of struct's functionality, it's documenting and
verifying a fundamental _belief_ of the test author's: the test
itself is buggy if that assert ever triggers. Or, IOW, it's being
used for what an assert statement should be used for :-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UUID module
Phillip J. Eby wrote: At 06:39 PM 6/10/2006 +0200, Thomas Heller wrote: I don't know if this is the uuidgen you're talking about, but on linux there is libuuid: from ctypes import * lib = CDLL(libuuid.so.1) uuid = create_string_buffer(16) lib.uuid_generate(byref(uuid)) 2131088494 from binascii import hexlify hexlify(buffer(uuid)) '0c77b6d7e5f940b18e29a749057f6ed4' Nice. :) But no, this one's a uuidgen() system call on FreeBSD=5.0 and NetBSD=2.0; it may be in other BSD variants as well... perhaps OS X? For completeness :-), although its probably getting off-topic: $ uname -a FreeBSD freebsd 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Thu Nov 3 09:36:13 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 $ python Python 2.4.1 (#2, Oct 12 2005, 01:36:32) [GCC 3.4.4 [FreeBSD] 20050518] on freebsd6 Type help, copyright, credits or license for more information. from ctypes.util import find_library find_library(c) 'libc.so.6' from ctypes import * libc = CDLL(libc.so.6) uuid = create_string_buffer(16) libc.uuidgen(uuid, 1) 0 uuid[:] '\xd2\xff\x8e\xe3\xa3\xf8\xda\x11\xb0\x04\x00\x0c)\xd1\x18\x06' $ On OS X, this call is not available, but /usr/lib/libc.dylib has a uuid_generate function which is apparently compatible to the linux example I posted above. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] beta1 coming real soon
On Sat, Jun 10, 2006, Ronald Oussoren wrote: Hopefully Python 2.5 will see more testing on the mac because there will be prompt binary releases of the betas this time around. If there is in fact a binary beta release for OS X, there will definitely be testing because we need to double-check all our 2.5 claims for Python for Dummies (and my co-author only uses a Mac). -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ I saw `cout' being shifted Hello world times to the left and stopped right there. --Steve Gonedes ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a note in random.shuffle.__doc__ ...
Alex Martelli [EMAIL PROTECTED] wrote: ...claims: Note that for even rather small len(x), the total number of permutations of x is larger than the period of most random number generators; this implies that most permutations of a long sequence can never be generated. [snip] I suspect that the note is just a fossil from a time when the default random number generator was Whichman-Hill, with a much shorter period. Should this note just be removed, or instead somehow reworded to point out that this is not in fact a problem for the module's current default random number generator? Opinions welcome! I'm recovering from a migraine, but here are my thoughts on the topic... The number of permutations of n items is n!, which is (n/2)^(n/2). Solve: 2**19997 (n/2)^(n/2) log_2(2**19997) log_2((n/2)^(n/2)) 19997 (n/2)*log(n/2) Certainly with n = 4096, the above holds (2048 * 11 = 22528) - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] beta1 coming real soon
On 10-jun-2006, at 21:32, Aahz wrote: On Sat, Jun 10, 2006, Ronald Oussoren wrote: Hopefully Python 2.5 will see more testing on the mac because there will be prompt binary releases of the betas this time around. If there is in fact a binary beta release for OS X, there will definitely be testing because we need to double-check all our 2.5 claims for Python for Dummies (and my co-author only uses a Mac). There will be a binary release and I'll be making it :-). Does Python for Dummies cover using the Carbon package (the part that seems to get limited testing)? Given the title of the book I'd be (pleasantly) surprised. Ronald ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UUID module
Paul Moore wrote: On 6/10/06, Ka-Ping Yee [EMAIL PROTECTED] wrote: ...so i looked at PEAK's getnodeid48() routine and borrowed the Win32 calls from there, with a comment giving attribution to PEAK. Instead of using pywin32, could you use ctypes, as that's part of core Python? It looks like the only Win32 API you use is CoCreateGUID, so wrapping it should be doable... http://docs.python.org/dev/lib/module-msilib.html#l2h-5633 Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UUID module
Thomas On OS X, this call is not available, but /usr/lib/libc.dylib has Thomas a uuid_generate function which is apparently compatible to the Thomas linux example I posted above. Confirmed: % python Python 2.5a2 (trunk:46644M, Jun 4 2006, 10:58:16) [GCC 4.0.0 (Apple Computer, Inc. build 5026)] on darwin Type help, copyright, credits or license for more information. from ctypes.util import find_library print find_library(c) /usr/lib/libc.dylib from ctypes import * libc = CDLL(libc.dylib) uuid = create_string_buffer(16) libc.uuid_generate(uuid, 1) -1073747536 print repr(uuid[:]) '[EMAIL PROTECTED]' Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a note in random.shuffle.__doc__ ...
Josiah Carlson [EMAIL PROTECTED] wrote: Alex Martelli [EMAIL PROTECTED] wrote: ...claims: Note that for even rather small len(x), the total number of permutations of x is larger than the period of most random number generators; this implies that most permutations of a long sequence can never be generated. [snip] I suspect that the note is just a fossil from a time when the default random number generator was Whichman-Hill, with a much shorter period. Should this note just be removed, or instead somehow reworded to point out that this is not in fact a problem for the module's current default random number generator? Opinions welcome! I'm recovering from a migraine, but here are my thoughts on the topic... The number of permutations of n items is n!, which is (n/2)^(n/2). Solve: 2**19997 (n/2)^(n/2) log_2(2**19997) log_2((n/2)^(n/2)) 19997 (n/2)*log(n/2) Certainly with n = 4096, the above holds (2048 * 11 = 22528) - Josiah I would also point out that even if MT had a larger period, there would still be no guarantee that all permutations of a given sequence would be able to be generated from the PRNG given some aribtrary internal state. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] wsgiref doc draft; reviews/patches wanted
On 6/9/06, Phillip J. Eby [EMAIL PROTECTED] wrote: 4. I believe the order of submodules presented is important and think that they should be listed with 'handlers' and 'simple_server' first: I agree that the order is important, but I intentionally chose the current order to be a gentle slope of complexity, from the near-trivial functions on up to the server/handler framework last. I'm not sure what ordering principle you're suggesting to use instead. When I first hit the documentation I was confused by the order. This is wsgiref, a reference implementation of wsgi and I expected wsgi servers and middleware, actual implementations of WSGI, to be the most prominent part of the library and thus presented first. The utility functions would come afterward, after you got the basic wsgi pieces in place. -joe -- Joe Gregoriohttp://bitworking.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Segmentation fault in collections.defaultdict
An aside before I report this bug:_I_HATE_SOURCEFORGE_. If it doesn't bloody accept anonymous bug reports then it bloody well shouldn't let you type in a nice, detailed, well through-out report and then toss it in the toilet when you hit Submit, and also not allow one dive in after it by using the browser back button to recover the text. AAARRGGHH!! Anyhow, back to our regularly scheduled bug report, which as we know should have gone to Sourceforge, but isn't because I don't have time for more of that particular form of masochism. (If that doesn't sit well with you, then feel free to ignore any scribblings below.) Try this at home:import collectionsd=collections.defaultdict(int)d.iterkeys().next() # Seg faultd.iteritems().next() # Seg faultd.itervalues().next() # Fine and dandyPython version: Python 2.5a2 (trunk:46822M, Jun 10 2006, 13:14:15)[GCC 4.0.2 20050901 (prerelease) (SUSE Linux)] on linux2Discussion:The segmentation fault only occurs where we'd expect StopIteration to be raised. ie, if the defaultdict has 3 elements, then only the fourth call will result in a segmentation fault. Based on the following traceback, The failure occurs at dictobject.c:dictiter_iternextkey:2204, which attempts to INCREF the next non-existent key in the sequence. Thus the current code does not properly detect when it has run out of elements.Not having an intimate knowledge of the internals of dictobject.c or the new defaultdict implementation, the underlying problem is not immediately apparent. I wish I had more time to follow up on this, but my random poking around time is already overdrawn and I must get back to less enjoyable pursuits. Traceback: gdb ./pythonGNU gdb 6.3Copyright 2004 Free Software Foundation, Inc.GDB is free software, covered by the GNU General Public License, and you arewelcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions.There is absolutely no warranty for GDB. Type show warranty for details.This GDB was configured as x86_64-suse-linux...Using host libthread_db library /lib64/tls/libthread_db.so.1. (gdb) r t.pyStarting program: src/python-trunk/python t.py[Thread debugging using libthread_db enabled][New Thread 46912504205344 (LWP 12545)]Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46912504205344 (LWP 12545)]dictiter_iternextkey (di=0x2ab980a0) at dictobject.c:22042204 Py_INCREF(key);(gdb) back#0 dictiter_iternextkey (di=0x2ab980a0) at dictobject.c :2204#1 0x00460366 in wrap_next (self=value optimized out, args=value optimized out, wrapped=value optimized out) at typeobject.c:3846#2 0x00415adc in PyObject_Call (func=0x2ab90a50, arg=0x2aac2050, kw=0x0) at abstract.c:1802#3 0x00481217 in PyEval_EvalFrameEx (f=0x6df8f0, throwflag=value optimized out) at ceval.c:3776#4 0x00483a81 in PyEval_EvalCodeEx (co=0x2ab7daf8, globals=value optimized out, locals=value optimized out, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ceval.c:2832#5 0x00483ce2 in PyEval_EvalCode (co=value optimized out, globals=value optimized out, locals=value optimized out) at ceval.c:494#6 0x004a52f7 in PyRun_FileExFlags (fp=0x654010, filename=0x7fc96546 t.py, start=value optimized out, globals=0x677070, locals=0x677070, closeit=1, flags=0x7fc95300) at pythonrun.c:1232#7 0x004a5612 in PyRun_SimpleFileExFlags (fp=value optimized out, filename=0x7fc96546 t.py, closeit=1, flags=0x7fc95300) at pythonrun.c:856#8 0x00411cbd in Py_Main (argc=value optimized out, argv=0x7fc95418) at main.c:494#9 0x2b0515aa in __libc_start_main () from /lib64/tls/libc.so.6#10 0x004112ba in _start () at start.S:113 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a note in random.shuffle.__doc__ ...
Alex Martelli wrote: ...claims: Note that for even rather small len(x), the total number of permutations of x is larger than the period of most random number generators; this implies that most permutations of a long sequence can never be generated. Now -- why would the behavior of most random number generators be relevant here? The module's docs claim, for its specific Mersenne Twister generator, a period of 2**19997-1, which is (e.g.) a comfortable 130128673800676351960752618754658780303412233749552410245124492452914636 028095467780746435724876612802011164778042889281426609505759158196749438 742986040468247017174321241233929215223326801091468184945617565998894057 859403269022650639413550466514556014961826309062543 times larger than the number of permutations of 2000 items, which doesn't really feel to me like a rather small len(x) in this context (what I'm most often shuffling is just a pack of cards -- len(x)==52 -- for example). I wouldn't be too comfortable with that margin. The fun thing about factorials is that they add up really quickly. The crossover point is between 2080 and 2081. In [28]: from scipy import * In [29]: def f(x): : return special.gammaln(x-1) - 19937*log(2) : In [30]: optimize.brentq(f, 2000, 3000) Out[30]: 2082.4031300820125 In [31]: import gmpy In [32]: mtperiod = 2**19937 - 1 In [33]: for i in range(2075, 2085): : if gmpy.fac(i) mtperiod: : print i : break : : 2081 I think that documenting this boundary might be worthwhile rather than making vague references to small len(x). A note along the lines of Josiah wrote about there being no guarantees despite period size would also be useful. OTOH, isn't the exact PRNG algorithm considered an implementation detail? It certainly was when the module migrated from Wichmann-Hill to the Mersenne Twister. OTGH, I don't foresee the random module ever using an algorithm with worse characteristics than the Mersenne Twister. -- 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a note in random.shuffle.__doc__ ...
[Alex Martelli] ...claims: Note that for even rather small len(x), the total number of permutations of x is larger than the period of most random number generators; this implies that most permutations of a long sequence can never be generated. Now -- why would the behavior of most random number generators be relevant here? The module's docs claim, for its specific Mersenne Twister generator, a period of 2**19997-1, which is (e.g.) Oops! That's wrong. The period is 2**19937-1. a comfortable 130128673800676351960752618754658780303412233749552410245124492452914636 028095467780746435724876612802011164778042889281426609505759158196749438 742986040468247017174321241233929215223326801091468184945617565998894057 859403269022650639413550466514556014961826309062543 times larger than the number of permutations of 2000 items, which doesn't really feel to me like a rather small len(x) in this context (what I'm most often shuffling is just a pack of cards -- len(x)==52 -- for example). I suspect that the note is just a fossil from a time when the default random number generator was Whichman-Hill, with a much shorter period. Should this note just be removed, or instead somehow reworded to point out that this is not in fact a problem for the module's current default random number generator? Opinions welcome! It should be removed now. I'll do that :-) WH's period was indeed so short that it couldn't generate even a tiny fraction of the permutations of a deck of cards, and that's why the note was added. While a long period is necessary to get a shot at all permutations, it's not sufficient, and I don't know what the true story is wrt the Twister. For example, a miserable PRNG that returns 0.1, 0.1, 0.2, 0.1, 0.2, 0.2, 0.1, 0.2, 0.2, 0.2, 0.1, 0.2, 0.2, 0.2, 0.2, ... has infinite period, but has few (O(N)) distinct subsequences of length N. That's a failure of so-called equidistribution in N dimensions (for sufficiently large N, some N-vectors appear more often than others across the whole period). A long period is necessary but not sufficient for high-dimensional equidistribution. Off the top of my head, then, since the Twister is provably equidistributed in 623 dimensions to 32-bit accuracy, I expect it should be able to fairly generate all permutations of a sequence of = 623 elements (equidistribution in N dimensions implies equidistribution in all dimensions = N). So I'm happy to leave a warning out until the casinos switch to 12-deck blackjack ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a note in random.shuffle.__doc__ ...
On Jun 10, 2006, at 1:08 PM, Josiah Carlson wrote: Josiah Carlson [EMAIL PROTECTED] wrote: Alex Martelli [EMAIL PROTECTED] wrote: ...claims: Note that for even rather small len(x), the total number of permutations of x is larger than the period of most random number generators; this implies that most permutations of a long sequence can never be generated. [snip] I suspect that the note is just a fossil from a time when the default random number generator was Whichman-Hill, with a much shorter period. Should this note just be removed, or instead somehow reworded to point out that this is not in fact a problem for the module's current default random number generator? Opinions welcome! I'm recovering from a migraine, but here are my thoughts on the topic... The number of permutations of n items is n!, which is (n/2)^(n/2). Solve: 2**19997 (n/2)^(n/2) log_2(2**19997) log_2((n/2)^(n/2)) 19997 (n/2)*log(n/2) Certainly with n = 4096, the above holds (2048 * 11 = 22528) - Josiah I would also point out that even if MT had a larger period, there would still be no guarantee that all permutations of a given sequence would be able to be generated from the PRNG given some aribtrary internal state. Sure. And an n of 2081 happens to suffice: period = 2**19937 while gmpy.fac(i) period: i = i +1 ... i 2081 Still, the note, as worded, is misleading -- it strongly suggests that for even small len(x) (no mention of whether that means dozens or thousands) the RNG can't generate all permutations, with no proof either way and just a misleading hint. The values of N such that the RNG can generate all permutations of a sequence of len(N) are not precisely known at this time might be closer to the truth (if this is, indeed, the state of our collective knowledge). Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a note in random.shuffle.__doc__ ...
That doc note should surely be removed. Perhaps it's an artifact from some earlier shuffle algorithm. The current algorithm (which is simple, well known, and which produces all permutations with equal probability) only calls the RNG len(x) - 1 times. Terry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] beta1 coming real soon
Barry Warsaw wrote: On Fri, 9 Jun 2006 09:54:29 -0700 Brett Cannon [EMAIL PROTECTED] wrote: Do enough people use Google Calendar or a calendar app that support iCal feeds that it would be useful for someone to maintain a Gcal calendar that has the various Python dev related dates in it? Great idea! Won't help myself too much - I use a sheet of paper on the wall as a calendar. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Add pure python PNG writer module to stdlib?
I'm working on simple module to write PNG image files in pure python. Adding it to the standard library would be useful for people who want to create images on web server installations without gd and imlib, or on platforms where the netpbm tools are not easily available. Does anybody find this idea interesting? Does anybody think it could go into stdlib before the feature freeze for 2.5? The module consists of only one file. It imports only sys, zlib, struct (maybe re for testing). Some benchmarks for comparison with the pnmtopng program (from netpbm), encoding a plain RGB file with 24 bits per pixel, input file size 11520017 bytes (11M), measured with the 'time' command, including Python interpreter start-up: pnmtopngpng.py straight encoding 1.31 seconds0.72 seconds resulting file size 342953 bytes292885 bytes interlaced encoding 3.78 seconds4.88 seconds resulting file size 422441 bytes346872 bytes The source code of the module lives here: http://svn.browsershots.org/trunk/shotfactory/lib/image/png.py http://trac.browsershots.org/browser/trunk/shotfactory/lib/image/png.py I am willing to maintain the module for 5+ years, as it is a small but important part of my main project. I am also willing to write latex documentation and tests for the module, and I think I could do that within the next three days. The module is licensed under the Apache License 2.0, and I am ready to sign a contributor agreement for the PSF. I will probably add support for more different PNG formats, especially alpha channel transparency, and then maybe color palettes. I don't plan to add PNG decoding because it would make the module much larger and rather complex. Sorry if this contribution seems brash. Perhaps it is easy enough to download and deploy my module separately. But I thought that if there is a chance to get it in before beta1, I should not hesitate and just ask. Cheers, Johann ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add pure python PNG writer module to stdlib?
Johann C. Rocholl wrote: I'm working on simple module to write PNG image files in pure python. Adding it to the standard library would be useful for people who want to create images on web server installations without gd and imlib, or on platforms where the netpbm tools are not easily available. Does anybody find this idea interesting? Does anybody think it could go into stdlib before the feature freeze for 2.5? +1 Michael Foord The module consists of only one file. It imports only sys, zlib, struct (maybe re for testing). Some benchmarks for comparison with the pnmtopng program (from netpbm), encoding a plain RGB file with 24 bits per pixel, input file size 11520017 bytes (11M), measured with the 'time' command, including Python interpreter start-up: pnmtopngpng.py straight encoding 1.31 seconds0.72 seconds resulting file size 342953 bytes292885 bytes interlaced encoding 3.78 seconds4.88 seconds resulting file size 422441 bytes346872 bytes The source code of the module lives here: http://svn.browsershots.org/trunk/shotfactory/lib/image/png.py http://trac.browsershots.org/browser/trunk/shotfactory/lib/image/png.py I am willing to maintain the module for 5+ years, as it is a small but important part of my main project. I am also willing to write latex documentation and tests for the module, and I think I could do that within the next three days. The module is licensed under the Apache License 2.0, and I am ready to sign a contributor agreement for the PSF. I will probably add support for more different PNG formats, especially alpha channel transparency, and then maybe color palettes. I don't plan to add PNG decoding because it would make the module much larger and rather complex. Sorry if this contribution seems brash. Perhaps it is easy enough to download and deploy my module separately. But I thought that if there is a chance to get it in before beta1, I should not hesitate and just ask. Cheers, Johann ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a note in random.shuffle.__doc__ ...
[Terry Jones] That doc note should surely be removed. Perhaps it's an artifact from some earlier shuffle algorithm. No, it's an artifact form an earlier PRNG. The shuffle algorithm hasn't changed. The current algorithm (which is simple, well known, Both true. and which produces all permutations with equal probability) That needs proof. Assuming a true random number generator, such a proof is easy. Using a deterministic PRNG, if the period is too short it's dead easy (see below) to prove that it can't produce all permutations (let alone with equal probablility). only calls the RNG len(x) - 1 times. And that's irrelevant. When a PRNG has period P, then _no_ deterministic algorithm (for shuffling or anything else) using that PRNG can possibly produce more than P distinct outcomes: the position in the period when you start the algorithm entirely determines the outcome, and there are only P _possible_ starting positions. For the older WH PRNG, P was much smaller than 52!, so it was just that easy to _know_ that not all deck-of-card shufflings could be produced. The newer Mersenne Twister PRNG has a vastly larger period, and more to the point has provably excellent equidistribution properties in 52 dimensions. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Thomas As the subject of this e-mail says, the attached patch adds a Thomas switch statement to the Python language. Thanks for the contribution. I patched my sandbox and it built just fine. I'm going out of town for a couple weeks, so I'll point out what everyone else is thinking then duck out of the way: * Aside from the modified Grammar file there is no documentation. * There are no test cases. * Can you submit a patch on SourceForge? Other than that, my trivial first attempt worked fine: #!/usr/bin/env python switch raw_input(enter a, b or c: ): case 'a': print 'yay! an a!' case 'b': print 'yay! a b!' case 'c': print 'yay! a c!' else: print 'hey dummy! I said a, b or c!' (Need to teach python-mode about the switch and case keywords.) You mentioned: Thomas I got a bit lost as to why the SWITCH opcode is necessary for Thomas the implementation of the PEP. The reasoning seems to be Thomas improving performance, but I'm not sure how a new opcode could Thomas improve performance. Your implementation is straightforward, but uses a series of DUP_TOP and COMPARE_OP instructions to compare each alternative expression to the initial expression. In many other languages the expression associated with the case would be restricted to be a constant expression so that at compile time a jump table or dictionary lookup could be used to jump straight to the desired case. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a note in random.shuffle.__doc__ ...
Tim == Tim Peters [EMAIL PROTECTED] writes: Tim [Terry Jones] and which produces all permutations with equal probability) Tim That needs proof. Assuming a true random number generator, such a Tim proof is easy. Using a deterministic PRNG, if the period is too Tim short it's dead easy (see below) to prove that it can't produce all Tim permutations (let alone with equal probablility). OK, thanks. Sorry for the noise. Terry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add pure python PNG writer module to stdlib?
On 6/10/06, Johann C. Rocholl [EMAIL PROTECTED] wrote: I'm working on simple module to write PNG image files in pure python.Adding it to the standard library would be useful for people who wantto create images on web server installations without gd and imlib, oron platforms where the netpbm tools are not easily available. Does anybody find this idea interesting?Yes, although I wouldn't want an interface taking in strings but something more like an iterator that returns each row which itself contains int triples. In other words more array-based than string based. Does anybody think it could go into stdlib before the feature freeze for 2.5? Nope. To get added to the stdlib there needs to be support from the community that the module is useful and best-of-breed. Try posting on c.l.py and see if people pick it up and like it. No way that is going to happen before b1. But there is always 2.6 .-Brett The module consists of only one file. It imports only sys, zlib, struct (maybe re for testing).Some benchmarks for comparison with the pnmtopng program (fromnetpbm), encoding a plain RGB file with 24 bits per pixel, input filesize 11520017 bytes (11M), measured with the 'time' command, including Python interpreter start-up:pnmtopngpng.pystraight encoding 1.31 seconds0.72 secondsresulting file size 342953 bytes292885 bytesinterlaced encoding 3.78 seconds4.88 secondsresulting file size 422441 bytes346872 bytesThe source code of the module lives here:http://svn.browsershots.org/trunk/shotfactory/lib/image/png.py http://trac.browsershots.org/browser/trunk/shotfactory/lib/image/png.pyI am willing to maintain the module for 5+ years, as it is a small but important part of my main project. I am also willing to write latexdocumentation and tests for the module, and I think I could do thatwithin the next three days. The module is licensed under the ApacheLicense 2.0, and I am ready to sign a contributor agreement for thePSF.I will probably add support for more different PNG formats, especiallyalpha channel transparency, and then maybe color palettes. I don'tplan to add PNG decoding because it would make the module much larger and rather complex.Sorry if this contribution seems brash. Perhaps it is easy enough todownload and deploy my module separately. But I thought that if thereis a chance to get it in before beta1, I should not hesitate and just ask.Cheers,Johann___Python-Dev mailing listPython-Dev@python.org http://mail.python.org/mailman/listinfo/python-devUnsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a note in random.shuffle.__doc__ ...
Robert Kern wrote: OTOH, isn't the exact PRNG algorithm considered an implementation detail? It's questionable whether the PRNG being used *should* be an implementation detail. To anyone who cares even a little bit about its quality, knowing the algorithm (or at least some info about it, such as the period) is vital. PRNGs are not like sorting algorithms, where different ones all give the same result in the end. Different PRNGs have *wildly* different characteristics. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a note in random.shuffle.__doc__ ...
Tim Peters wrote: Off the top of my head, then, since the Twister is provably equidistributed in 623 dimensions to 32-bit accuracy, I expect it should be able to fairly generate all permutations of a sequence of = 623 elements (equidistribution in N dimensions implies equidistribution in all dimensions = N). So I'm happy to leave a warning out until the casinos switch to 12-deck blackjack ;-) But isn't the problem with the Twister that for *some initial states* the period could be much *shorter* than the theoretical maximum? Or is the probability of getting such an initial state too small to worry about? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a note in random.shuffle.__doc__ ...
Terry Jones wrote: That doc note should surely be removed. Perhaps it's an artifact from some earlier shuffle algorithm. The current algorithm (which is simple, well known, and which produces all permutations with equal probability) only calls the RNG len(x) - 1 times. It's not a matter of how many times it's called, but of how much internal state it has. A generator with only N possible internal states can't possibly result in more than N different outcomes from any algorithm that uses its results. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
[EMAIL PROTECTED] wrote: switch raw_input(enter a, b or c: ): case 'a': print 'yay! an a!' case 'b': print 'yay! a b!' case 'c': print 'yay! a c!' else: print 'hey dummy! I said a, b or c!' Before accepting this, we could do with some debate about the syntax. It's not a priori clear that C-style switch/case is the best thing to adopt. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
And from a syntax perspective, it's a bad idea. x[] is much more often a typo than an intentional attempt to index a zero-dimensional array. but how often is it a typo? for example, judging from c.l.python traffic, forgetting to add a return statement is a quite common, but I haven't seen anyone arguing that we deprecate the implied return None behaviour. Sounds like a terrific idea. The implicit None behaviour has hit me many times and: something = somefunc() is almost always an error if somefunc() doesn't have an explicit return statement. I don't know how difficult it is to get rid of the implicit return None or even if it is doable, but if it is, it should, IMHO, be done. -- mvh Björn ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a note in random.shuffle.__doc__ ...
Greg == Greg Ewing [EMAIL PROTECTED] writes: Greg A generator with only N possible internal states can't Greg possibly result in more than N different outcomes from Greg any algorithm that uses its results. I don't mean to pick nits, but I do find this a bit too general. Suppose you have a RNG with a cycle length of 5. There's nothing to stop an algorithm from taking multiple already returned values and combining them in some (deterministic) way to generate 5 outcomes. (Yes, those outcomes might be more, or less, predictable but that's not the point). If you expanded what you meant by internal states to include the state of the algorithm (as well as the state of the RNG), then I'd be more inclined to agree. Worse, if you have multiple threads / processes using the same RNG, the individual threads could exhibit _much_ more random behavior if individual thread outcomes depend on multiple RNG return values (as is the case with random.shuffle) and the scheduler is mixing things up. Here you'd have to include the state of the operating system to claim you can't get more outcomes than the number of internal states. But that's getting pretty far away from what we'd ordinarily think of as the internal state of the RNG. Terry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Greg Before accepting this, we could do with some debate about the Greg syntax. It's not a priori clear that C-style switch/case is the Greg best thing to adopt. Oh sure. That debate should probably leverage PEP 275. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add pure python PNG writer module to stdlib?
On Jun 10, 2006, at 4:35 PM, Brett Cannon wrote:On 6/10/06, Johann C. Rocholl [EMAIL PROTECTED] wrote: I'm working on simple module to write PNG image files in pure python.Adding it to the standard library would be useful for people who wantto create images on web server installations without gd and imlib, oron platforms where the netpbm tools are not easily available. Does anybody find this idea interesting?Yes, although I wouldn't want an interface taking in strings but something more like an iterator that returns each row which itself contains int triples. In other words more array-based than string based. Well you could easily make such strings (or a buffer object that could probably be used in place of a string) with the array module... -bob___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
On Sat, Jun 10, 2006 at 05:53:14PM -0500, [EMAIL PROTECTED] wrote: * Aside from the modified Grammar file there is no documentation. * There are no test cases. * Can you submit a patch on SourceForge? All have been addressed, although I'm not sure if I've covered everywhere I need to update for the documentation: http://sourceforge.net/tracker/index.php?func=detailaid=1504199group_id=5470atid=305470 Thanks again for your feedback! Cheers, Tom -- Tom Lee http://www.vector-seven.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a note in random.shuffle.__doc__ ...
[Greg Ewing] But isn't the problem with the Twister that for *some initial states* the period could be much *shorter* than the theoretical maximum? Or is the probability of getting such an initial state too small to worry about? The Twister's state is held in a vector of 624 32-bit words. 31 of the bits aren't actually used, and the number of meaningful state bits is actually 624 * 32 - 31 = 19937. There are exactly 2 orbits in the state space under the state transformation operation (STO): 1. A trivial orbit of length 1, consisting of the state in which all meaningful bits are 0. That's a fixed point for the STO. There are no other fixed points. 2. All not-entirely-0 states are in the other orbit, of length 2**19937 - 1. All not-0 states are reachable from all other not-0 states, and you get back to the non-zero state you start from for the first time after exactly 2**19937 - 1 iterations of the STO. So as long as you don't start with the all-0 state, you're in the second orbit, and see the advertised period (2**19937 - 1). From Python code, it's impossible to get the all-0 state. All Python-visible initialization methods guarantee there's at least one bit set in the meaningful bits of the state vector, so the probability of not seeing a period of 2**19937 - 1 from Python is exactly 0. Hmm. Well, there _is_ a way to screw yourself here, but you have to work at it: you can force the all-0 state by hand-crafting the right input to random.setstate(). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
Noam Raphael wrote: I hope that my (hopefully) better explanation made the use case more compelling, but I want to add two points in favour of an empty tuple: I guess I'm really only -0 on the idea of x[] invoking x.__getitem__(), and allowing the class to decide whether or not to define a default value for the subscript. I wouldn't implement it myself, but I wouldn't object strenuously if Guido decided it was OK :) For your specific use cases, though, I'd be inclined to tweak the API a bit, and switch to using attributes for the single-valued data: tax_rates.income_tax = 0.18 Although the income tax rate should actually depend on the current financial year, since it can change over time as the government increases taxes ;) Why? Mental exercise is a good way to keep you mental ;) Hehe :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add pure python PNG writer module to stdlib?
Does anybody find this idea interesting?
Yes, although I wouldn't want an interface taking in strings but something
more like an iterator that returns each row which itself contains int
triples. In other words more array-based than string based.
I agree that arrays would be semantically closer to the concept of
scanlines of pixel values. OTOH, I have my reasons for choosing the
string interface:
1. String is what you get from any file-like object with file.read(),
be it a PPM file on disk, or a pipe like this: os.popen('djpeg
test.jpg')
2. String is unbeatable in terms of efficiency.
3. Everybody knows how to use strings.
4. String can easily be created from other representations, for example:
from array import array
B = array('B')
B.extend((255, 255, 255))
B.tostring()
'\xff\xff\xff'
Does anybody think it could go into stdlib before the feature freeze for
2.5?
Nope. To get added to the stdlib there needs to be support from the
community that the module is useful and best-of-breed. Try posting on
c.l.py and see if people pick it up and like it. No way that is going to
happen before b1. But there is always 2.6 .
That's what I thought. My remote hope was that there would be
immediate concensus on python-dev about both the 'useful' and
'best-of-breed' parts. Anybody else with a +1? ;-)
Seriously, it's totally fine with me if the module doesn't make it
into 2.5, or even if it never makes it into stdlib. I'm just offering
it with some enthusiasm.
Cheers,
Johann
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
