Re: [Python-Dev] deja-vu .. python locking
Martin Devera <[EMAIL PROTECTED]> wrote: [snip] > Even if you can do fast atomic inc/dec, it forces cacheline with > refcounter to ping-pong between caches of referencing cpus (for read only > class dicts for example) so that you can probably never get good SMP > scalability. That's ok. Why? Because according to Guido, the GIL isn't going away: http://mail.python.org/pipermail/python-3000/2006-April/001072.html ... so ruminations about refcounting, GC, etc., at least with regards to removing the GIL towards some sort of "free threading" Python, are likely to go nowhere. Unless someone is able to translate the codebase into using such methods, show how it is not (significantly) more difficult to program extensions for, show a mild to moderate slowdown on single processors, and prove actual speedup on multiple processors. But even then it will be a difficult sell, as it would require possibly radical rewrites for all of the hundreds or thousands of CPython extensions currently being developed and maintained. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Exceptions and slicing
Is it an oversight that exception instances do no longer support
slicing in Python 2.5?
This code works in 2.4, but no longer in 2.5:
try:
open("", "r")
except IOError, details:
print details[:]
Thomas
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exceptions and slicing
On 9/20/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
Is it an oversight that exception instances do no longer supportslicing in Python 2.5?This code works in 2.4, but no longer in 2.5:try:open("", "r")except IOError, details:
print details[:]Technically, yes. There is no entry in the sq_slice field for the PySequenceMethods struct. Although you can get to the list of arguments by going through the 'args' attribute if you need a quick fix.
I have a fix in my checkout that I will check into the trunk shortly and into 25-maint as soon as Anthony unfreezes it.-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exceptions and slicing
Brett Cannon schrieb:
> On 9/20/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>>
>> Is it an oversight that exception instances do no longer support
>> slicing in Python 2.5?
>>
>> This code works in 2.4, but no longer in 2.5:
>>
>> try:
>> open("", "r")
>> except IOError, details:
>> print details[:]
>
>
> Technically, yes. There is no entry in the sq_slice field for the
> PySequenceMethods struct. Although you can get to the list of arguments by
> going through the 'args' attribute if you need a quick fix.
Well, Nick Coghlan pointed out in private email:
>> According to PEP 352 it should have at most been deprecated along with the
>> rest of Exception.__getitem__:
>>
>> "This also means providing a __getitem__ method is unneeded for exceptions
>> and
>> thus will be deprecated as well."
> I have a fix in my checkout that I will check into the trunk shortly and
> into 25-maint as soon as Anthony unfreezes it.
I was not aware before I posted that tuple-unpacking of exceptions still works,
so this is another possibility:
except WindowsError, (errno, message):
What I find worse about WindowsError especially is two things:
1. The __str__ of a WindowsError instance hides the 'real' windows
error number. So, in 2.4 "print error_instance" would print
for example:
[Errno 1002] Das Fenster kann die gesendete Nachricht nicht verarbeiten.
while in 2.5:
[Error 22] Das Fenster kann die gesendete Nachricht nicht verarbeiten.
because the new mapping of windows error codes to posix error codes creates
EINVAL (22) when no corresponding posix error code exists.
2. How would one write portable exception handling for Python 2.4 and 2.5?
I have code like this:
try:
do something
except WindowsError, details:
if not details.errno in (TYPE_E_REGISTRYACCESS, TYPE_E_CANTLOADLIBRARY):
raise
Doesn't work in 2.5 any longer, because I would have to use details.winerror
instead of e.errno.
The two portale possibilities I found are these, but neither is elegant imo:
except WindowsError, (winerrno, message):
or
except WindowsError, details:
winerrno = details[0]
And the latter still uses __getitem__ which may go away according to PEP 352.
Thomas
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exceptions and slicing
Thomas Heller schrieb: > 1. The __str__ of a WindowsError instance hides the 'real' windows > error number. So, in 2.4 "print error_instance" would print > for example: > > [Errno 1002] Das Fenster kann die gesendete Nachricht nicht verarbeiten. > > while in 2.5: > > [Error 22] Das Fenster kann die gesendete Nachricht nicht verarbeiten. That's a bug. I changed the string deliberately from Errno to error to indicate that it is not an errno, but a GetLastError. Can you come up with a patch? > 2. How would one write portable exception handling for Python 2.4 and 2.5? > > I have code like this: > > try: > do something > except WindowsError, details: > if not details.errno in (TYPE_E_REGISTRYACCESS, TYPE_E_CANTLOADLIBRARY): > raise > > Doesn't work in 2.5 any longer, because I would have to use details.winerror > instead of e.errno. Portable code should do def winerror(exc): try: return exc.winerror except AttributeError: #2.4 and earlier return exc.errno and then try: do something except WindowsError, details: if not winerror(details) in (TYPE_E_REGISTRYACCESS, YPE_E_CANTLOADLIBRARY): raise Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exceptions and slicing
On 9/20/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
Brett Cannon schrieb:> On 9/20/06, Thomas Heller <[EMAIL PROTECTED]> wrote: Is it an oversight that exception instances do no longer support
>> slicing in Python 2.5? This code works in 2.4, but no longer in 2.5: try:>> open("", "r")>> except IOError, details:
>> print details[:]>>> Technically, yes. There is no entry in the sq_slice field for the> PySequenceMethods struct. Although you can get to the list of arguments by> going through the 'args' attribute if you need a quick fix.
Well, Nick Coghlan pointed out in private email:>> According to PEP 352 it should have at most been deprecated along with the>> rest of Exception.__getitem__: "This also means providing a __getitem__ method is unneeded for exceptions and
>> thus will be deprecated as well."Right, the deprecation is not scheduled until Python 2.9 for __getitem__ so it was a regression problem (was never a test for it before PEP 352 was written). The fix is now in so your code should work again from a trunk checkout. I will backport when the freeze is raised.
-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exceptions and slicing
Martin v. Löwis schrieb: > Thomas Heller schrieb: >> 1. The __str__ of a WindowsError instance hides the 'real' windows >> error number. So, in 2.4 "print error_instance" would print >> for example: >> >> [Errno 1002] Das Fenster kann die gesendete Nachricht nicht verarbeiten. >> >> while in 2.5: >> >> [Error 22] Das Fenster kann die gesendete Nachricht nicht verarbeiten. > > That's a bug. I changed the string deliberately from Errno to error to > indicate that it is not an errno, but a GetLastError. Can you come up > with a patch? Yes, but not today. >> 2. How would one write portable exception handling for Python 2.4 and 2.5? >> > Portable code should do > > def winerror(exc): > try: > return exc.winerror > except AttributeError: #2.4 and earlier > return exc.errno > > and then > > try: > do something > except WindowsError, details: > if not winerror(details) in (TYPE_E_REGISTRYACCESS, > YPE_E_CANTLOADLIBRARY): > raise Ok (sigh ;-). Thanks, Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 419 open ( +3) / 3410 closed ( +2) / 3829 total ( +5) Bugs: 910 open (+12) / 6185 closed ( +5) / 7095 total (+17) RFE : 235 open ( +1) / 238 closed ( +0) / 473 total ( +1) New / Reopened Patches __ Practical ctypes example (2006-09-15) http://python.org/sf/1559219 opened by leppton pyclbr reports different module for Class and Function (2006-09-18) http://python.org/sf/1560617 opened by Peter Otten Exec stacks in python 2.5 (2006-09-18) http://python.org/sf/1560695 opened by Chaza Patches Closed __ test_grp.py doesn't skip special NIS entry, fails (2006-06-22) http://python.org/sf/1510987 closed by martineau New / Reopened Bugs ___ some section links (previous, up, next) missing last word (2006-09-15) http://python.org/sf/1559142 opened by Tim Smith time.strptime() access non exitant attribute in calendar.py (2006-09-15) CLOSED http://python.org/sf/1559515 opened by betatim shutil.copyfile incomplete on NTFS (2006-09-16) http://python.org/sf/1559684 opened by Roger Upole gcc trunk (4.2) exposes a signed integer overflows (2006-08-24) http://python.org/sf/1545668 reopened by arigo 2.5c2 pythonw does not execute (2006-09-16) http://python.org/sf/1559747 opened by Ron Platten list.sort does nothing when both cmp and key are given (2006-09-16) CLOSED http://python.org/sf/1559818 opened by Marcin 'Qrczak' Kowalczyk confusing error msg from random.randint (2006-09-17) http://python.org/sf/1560032 opened by paul rubin Tutorial: incorrect info about package importing and mac (2006-09-17) http://python.org/sf/1560114 opened by C L Better/faster implementation of os.path.split (2006-09-17) CLOSED http://python.org/sf/1560161 opened by Michael Gebetsroither Better/faster implementation of os.path.basename/dirname (2006-09-17) http://python.org/sf/1560179 reopened by gbrandl Better/faster implementation of os.path.basename/dirname (2006-09-17) http://python.org/sf/1560179 opened by Michael Gebetsroither copy() method of dictionaries is not "deep" (2006-09-17) http://python.org/sf/1560327 reopened by gbrandl copy() method of dictionaries is not "deep" (2006-09-17) http://python.org/sf/1560327 opened by daniel hahler python 2.5 fails to build with --as-needed (2006-09-18) http://python.org/sf/1560984 opened by Chaza mac installer profile patch vs. .bash_login (2006-09-19) http://python.org/sf/1561243 opened by Ronald Oussoren -xcode=pic32 option is not supported on Solaris x86 Sun C (2006-09-19) http://python.org/sf/1561333 opened by James Lick Dedent with Italian keyboard (2006-09-20) http://python.org/sf/1562092 opened by neclepsio Fails to install on Fedora Core 5 (2006-09-20) http://python.org/sf/1562171 opened by Mark Summerfield IDLE Hung up after open script by command line... (2006-09-20) http://python.org/sf/1562193 opened by Faramir^ uninitialized memory read in parsetok() (2006-09-20) http://python.org/sf/1562308 opened by Luke Moore Bugs Closed ___ 2.5c2 macosx installer aborts during "GUI Applications" (2006-09-15) http://python.org/sf/1558983 closed by ronaldoussoren time.strptime() access non existant attribute in calendar.py (2006-09-15) http://python.org/sf/1559515 closed by bcannon list.sort does nothing when both cmp and key are given (2006-09-16) http://python.org/sf/1559818 closed by qrczak Better/faster implementation of os.path.split (2006-09-17) http://python.org/sf/1560161 deleted by einsteinmg Better/faster implementation of os.path.basename/dirname (2006-09-17) http://python.org/sf/1560179 deleted by einsteinmg copy() method of dictionaries is not "deep" (2006-09-17) http://python.org/sf/1560327 closed by gbrandl New / Reopened RFE __ Exception need structured information associated with them (2006-09-15) http://python.org/sf/1559549 opened by Ned Batchelder String searching performance improvement (2006-09-19) CLOSED http://python.org/sf/1561634 opened by Nick Welch RFE Closed __ String searching performance improvement (2006-09-19) http://python.org/sf/1561634 deleted by mackstann ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New relative import issue
On 9/19/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > I haven't really thought it through in detail. It > just seems as though it would be a lot less confusing > if you could figure out from static information which > module will get imported by a given import statement, > instead of having it depend on the history of run-time > modifications to sys.path. One such kind of static > information is the layout of the filesystem. Eek? If there are two third-party top-level packages A and B, by different third parties, and A depends on B, how should A find B if not via sys.path or something that is sufficiently equivalent as to have the same problems? Surely every site shouldn't be required to install A and B in the same location (or in the same location relative to each other). I sympathize with the problems that exist with the current import mechanism, really, I do. Google feels the pain every day (alas, Google's requirements are a bit unusual, so they alone can't provide much guidance for a solution). But if you combine the various requirements: zip imports, import hooks of various sorts, different permissions for the owners of different packages that must cooperate, versioning issues (Python versions as well as package versions), forwards compatibility, backwards compatibility, ease of development, ease of packaging, ease of installation, supporting the conventions of vastly different platforms, data files mixed in with the source code (sometimes with their own search path), and probably several other requirements that I'm forgetting right now, it's just not an easy problem. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] IronPython and AST branch
On 9/17/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > One of the biggest issues I have with the current AST is that I don't believe > it really gets the "slice" and "extended slice" terminology correct (it uses > 'extended slice' to refer to multi-dimensional indexing, but the normal > meaning of that phrase is to refer to the use of a step argument for a slice > [1]) The two were introduced together and were referred to together as "extended slicing" at the time, so I'm not sure who is confused. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
