Re: [Python-Dev] cpython: Added tag v3.3.0b1 for changeset e15c554cd43e
It is done -- the beta is tagged. Thanks to everyone for your hard work, especially to the intrepid devs on IRC. Georg On 26.06.2012 09:43, georg.brandl wrote: http://hg.python.org/cpython/rev/fadcc985010b changeset: 77802:fadcc985010b user:Georg Brandl date:Tue Jun 26 09:43:46 2012 +0200 summary: Added tag v3.3.0b1 for changeset e15c554cd43e files: .hgtags | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/.hgtags b/.hgtags --- a/.hgtags +++ b/.hgtags @@ -103,3 +103,4 @@ 2f69db52d6de306cdaef0a0cc00cc823fb350b01 v3.3.0a2 0b53b70a40a00013505eb35e3660057b62be77be v3.3.0a3 7c51388a3aa7ce76a8541bbbdfc05d2d259a162c v3.3.0a4 +e15c554cd43eb23bc0a528a4e8741da9bbec9607 v3.3.0b1 ___ 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] itertools.chunks(iterable, size, fill=None)
Now that Python 3 is all about iterators (which is a user killer feature for Python according to StackOverflow - http://stackoverflow.com/questions/tagged/python) would it be nice to introduce more first class functions to work with them? One function to be exact to split string into chunks. itertools.chunks(iterable, size, fill=None) Which is the 33th most voted Python question on SO - http://stackoverflow.com/questions/312443/how-do-you-split-a-list-into-evenly-sized-chunks-in-python/312464 P.S. CC'ing to python-dev@ to notify about the thread in python-ideas. ___ 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] Poking about issue 1677
Hi guys, I just wanted to bring some more attention to issue #1677 , because I feel it's important and misunderstood. See: http://bugs.python.org/issue1677 The issue is that sometimes, if you press ctrl-c on Windows, instead of raising a KeyboardInterrupt, Python will exit completely. Because of this, any program that relies on ctrl-c/KeyboardInterrupt is not guaranteed to work on windows. Also, working with the interactive interpreter becomes really annoying for those with the habit of deleting the whole input line via ctrl-c. Some people that read the bug report think that this only happens if you hold down ctrl-c long enough or fast enough or some such thing. That's not so; it can happen just from pressing ctrl-c once. Whatever race condition here is not related to the timing gaps between presses of ctrl-c. The "test cases" of "hold down ctrl-c for a bit" are to conveniently reproduce, not a description of the problem. Hope this was the right place. #python-dev encouraged me to post here, so, yeah. And thanks for all your hard work making Python a pleasant place to be. :) -- Devin ___ 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] Poking about issue 1677
On 26/06/2012 11:51, Devin Jeanpierre wrote: > Hi guys, > > I just wanted to bring some more attention to issue #1677 , because I > feel it's important and misunderstood. See: > http://bugs.python.org/issue1677 > > The issue is that sometimes, if you press ctrl-c on Windows, instead > of raising a KeyboardInterrupt, Python will exit completely. Because > of this, any program that relies on ctrl-c/KeyboardInterrupt is not > guaranteed to work on windows. Also, working with the interactive > interpreter becomes really annoying for those with the habit of > deleting the whole input line via ctrl-c. > > Some people that read the bug report think that this only happens if > you hold down ctrl-c long enough or fast enough or some such thing. > That's not so; it can happen just from pressing ctrl-c once. Whatever > race condition here is not related to the timing gaps between presses > of ctrl-c. The "test cases" of "hold down ctrl-c for a bit" are to > conveniently reproduce, not a description of the problem. > > Hope this was the right place. #python-dev encouraged me to post here, > so, yeah. And thanks for all your hard work making Python a pleasant > place to be. :) Thanks, Devin. Definitely useful info. AFAICT you haven't added that particular snippet of info to the call. (ie the fact that even one press will trigger the issue). Please feel free to add; I notice that you're the last submitter, some time last year. Goodness knows if I'll get the time, but the natural thing would be to hunt down the uses of SetConsoleCtrlHandler to see what we're doing with them. TJG ___ 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] Poking about issue 1677
I just wanted to bring some more attention to issue #1677 , because I feel it's important and misunderstood. Please consider working even more on a solution then. If I had time to work on this, I'd run Python in a debugger, and see what happens. Finding out in what state Python is when it stops might be enough to create a solution. I find this very hard to reproduce. All of the versions reported to crash work fine for me most of the time, except that a small percentage (1 out of 5 starts perhaps) actually does crash. 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] Poking about issue 1677
On 26/06/2012 11:59, Tim Golden wrote: > On 26/06/2012 11:51, Devin Jeanpierre wrote: >> Hi guys, >> >> I just wanted to bring some more attention to issue #1677 , because I >> feel it's important and misunderstood. See: >> http://bugs.python.org/issue1677 >> >> The issue is that sometimes, if you press ctrl-c on Windows, instead >> of raising a KeyboardInterrupt, Python will exit completely. Because >> of this, any program that relies on ctrl-c/KeyboardInterrupt is not >> guaranteed to work on windows. Also, working with the interactive >> interpreter becomes really annoying for those with the habit of >> deleting the whole input line via ctrl-c. >> >> Some people that read the bug report think that this only happens if >> you hold down ctrl-c long enough or fast enough or some such thing. >> That's not so; it can happen just from pressing ctrl-c once. Whatever >> race condition here is not related to the timing gaps between presses >> of ctrl-c. The "test cases" of "hold down ctrl-c for a bit" are to >> conveniently reproduce, not a description of the problem. >> >> Hope this was the right place. #python-dev encouraged me to post here, >> so, yeah. And thanks for all your hard work making Python a pleasant >> place to be. :) > > Thanks, Devin. Definitely useful info. AFAICT you haven't added that > particular snippet of info to the call. (ie the fact that even one press > will trigger the issue). Please feel free to add; I notice that you're > the last submitter, some time last year. > > Goodness knows if I'll get the time, but the > natural thing would be to hunt down the uses of SetConsoleCtrlHandler to > see what we're doing with them. OK. We clearly *don't* set a console handler as I thought we did. Scratch that idea off the list. As Martin said: need to run this with a debugger attached to try to catch in action. TJG ___ 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] Poking about issue 1677
On 6/26/2012 6:51 AM, Devin Jeanpierre wrote: The issue is that sometimes, if you press ctrl-c on Windows, instead of raising a KeyboardInterrupt, Python will exit completely. Because of this, any program that relies on ctrl-c/KeyboardInterrupt is not guaranteed to work on windows. Also, working with the interactive interpreter becomes really annoying for those with the habit of deleting the whole input line via ctrl-c. Idle Shell, 3.3.0a4, Win 7does not seem to have this problem. Still up after 6000 ^Cs. It is better anyway, in multiple ways, than Command Prompt. (That does not help batch-mode programs, though.) That aside, perhaps the way it handles ^C might help. I did get the CP to close four times, each time after a few hundred to maybe a thousand ^Cs. It seems to require more than just one held down key press. I suspect the closures happened after the limited line buffer was filled and it was starting to delete the earliest lines. -- Terry Jan Reedy ___ 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] os.path.exists() / os.path.isdir() inconsistency when dealing with gvfs directories
I've just noticed a strange behavior when dealing with gvfs filesystems:
giampaolo@ubuntu:~$ python -c "import os;
print(os.path.exists('/home/giampaolo/.gvfs'))"
True
giampaolo@ubuntu:~$ sudo su
root@ubuntu:~# python -c "import os;
print(os.path.exists('/home/giampaolo/.gvfs'))"
False
This is due to os.stat() which internally fails with PermissionError (EACCES).
The same problem exists with os.path.isdir() which will return True as
limited user and False as root.
I'm not sure what's best to do here nor I know if there are other
cases other than when dealing with gvfs which can produce similar
behaviors but here's an idea:
- make os.path.exists() return True in case of PermissionError because
that's supposed to mean there's an existing path to deny access to
- fix isdir(), islink(), isfile() documentation pointing out that in
case of EACCES/EPERM or when dealing with exotic paths/fs it may
return incorrect results.
Comments?
--- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/
http://code.google.com/p/pysendfile/
___
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] os.path.exists() / os.path.isdir() inconsistency when dealing with gvfs directories
On 27Jun2012 01:49, Giampaolo Rodolà wrote:
| I've just noticed a strange behavior when dealing with gvfs filesystems:
|
| giampaolo@ubuntu:~$ python -c "import os;
| print(os.path.exists('/home/giampaolo/.gvfs'))"
| True
| giampaolo@ubuntu:~$ sudo su
| root@ubuntu:~# python -c "import os;
| print(os.path.exists('/home/giampaolo/.gvfs'))"
| False
|
| This is due to os.stat() which internally fails with PermissionError (EACCES).
| The same problem exists with os.path.isdir() which will return True as
| limited user and False as root.
| I'm not sure what's best to do here nor I know if there are other
| cases other than when dealing with gvfs which can produce similar
| behaviors but here's an idea:
|
| - make os.path.exists() return True in case of PermissionError because
| that's supposed to mean there's an existing path to deny access to
Definitely not.
Firstly, if I ask about "a/b/c" and am denied access to "a/b", then it
would be a lie to say "c" exists - it may not.
Secondly, that's not at all what the UNIX stat() call does, and these
library calls mirror stat() very closely, possibly identically. And that
it good, because people don't need to keep two models in their head: one
for what the OS actually does and one for what Python's close-to-the-OS
library calls do.
| - fix isdir(), islink(), isfile() documentation pointing out that in
| case of EACCES/EPERM or when dealing with exotic paths/fs it may
| return incorrect results.
I don't think False in incorrect. Arguably the docs should be clearer
that True means it exists and False means it does not, or could not be
accessed. A bit like the empty() tests on Queues etc; one side of the
test is strong (at least at the time of the test) and the other is weak.
So I'd be +0.5 for making the docs more clear that True is reliable and
False may merely mean "could not access".
And -1 on changing the semantics; I think they are correct.
Cheers,
--
Cameron Simpson
Against stupiditythe Gods themselves contend in vain!
___
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] os.path.exists() / os.path.isdir() inconsistency when dealing with gvfs directories
2012/6/27 Cameron Simpson :
> On 27Jun2012 01:49, Giampaolo Rodolà wrote:
> | I've just noticed a strange behavior when dealing with gvfs filesystems:
> |
> | giampaolo@ubuntu:~$ python -c "import os;
> | print(os.path.exists('/home/giampaolo/.gvfs'))"
> | True
> | giampaolo@ubuntu:~$ sudo su
> | root@ubuntu:~# python -c "import os;
> | print(os.path.exists('/home/giampaolo/.gvfs'))"
> | False
> |
> | This is due to os.stat() which internally fails with PermissionError
> (EACCES).
> | The same problem exists with os.path.isdir() which will return True as
> | limited user and False as root.
> | I'm not sure what's best to do here nor I know if there are other
> | cases other than when dealing with gvfs which can produce similar
> | behaviors but here's an idea:
> |
> | - make os.path.exists() return True in case of PermissionError because
> | that's supposed to mean there's an existing path to deny access to
>
> Definitely not.
>
> Firstly, if I ask about "a/b/c" and am denied access to "a/b", then it
> would be a lie to say "c" exists - it may not.
Right, I wasn't taking that into account.
> So I'd be +0.5 for making the docs more clear that True is reliable and
> False may merely mean "could not access".
+1.
I was about to propose a 'strict' parameter which lets the exception
propagate in case of errno != EACCES/EPERM but a doc fix is probably
just fine.
I'll file a bug report later today.
Regards,
--- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/
http://code.google.com/p/pysendfile/
___
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] [RELEASED] Python 3.3.0 beta 1
On behalf of the Python development team, I'm happy to announce the
first beta release of Python 3.3.0.
This is a preview release, and its use is not recommended in
production settings.
Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x. Major new features and changes
in the 3.3 release series are:
* PEP 380, syntax for delegating to a subgenerator ("yield from")
* PEP 393, flexible string representation (doing away with the
distinction between "wide" and "narrow" Unicode builds)
* A C implementation of the "decimal" module, with up to 80x speedup
for decimal-heavy applications
* The import system (__import__) now based on importlib by default
* The new "lzma" module with LZMA/XZ support
* PEP 397, a Python launcher for Windows
* PEP 405, virtual environment support in core
* PEP 420, namespace package support
* PEP 3151, reworking the OS and IO exception hierarchy
* PEP 3155, qualified name for classes and functions
* PEP 409, suppressing exception context
* PEP 414, explicit Unicode literals to help with porting
* PEP 418, extended platform-independent clocks in the "time" module
* PEP 412, a new key-sharing dictionary implementation that
significantly saves memory for object-oriented code
* PEP 362, the function-signature object
* The new "faulthandler" module that helps diagnosing crashes
* The new "unittest.mock" module
* The new "ipaddress" module
* The "sys.implementation" attribute
* A policy framework for the email package, with a provisional (see
PEP 411) policy that adds much improved unicode support for email
header parsing
* A "collections.ChainMap" class for linking mappings to a single unit
* Wrappers for many more POSIX functions in the "os" and "signal"
modules, as well as other useful functions such as "sendfile()"
* Hash randomization, introduced in earlier bugfix releases, is now
switched on by default
In total, almost 500 API items are new or improved in Python 3.3.
For a more extensive list of changes in 3.3.0, see
http://docs.python.org/3.3/whatsnew/3.3.html (*)
To download Python 3.3.0 visit:
http://www.python.org/download/releases/3.3.0/
Please consider trying Python 3.3.0 with your code and reporting any bugs
you may notice to:
http://bugs.python.org/
Enjoy!
(*) Please note that this document is usually finalized late in the release
cycle and therefore may have stubs and missing entries at this point.
--
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
___
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] [RELEASED] Python 3.3.0 beta 1
On 06/26/2012 11:10 PM, Georg Brandl wrote: On behalf of the Python development team, I'm happy to announce the first beta release of Python 3.3.0. I <3 <3.<3 Thanks Georg! And everybody who contributed. Stoked, //arry/ ___ 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
