[issue1065986] Fix pydoc crashing on unicode strings

[Stefano Taschini]

Changes by Stefano Taschini :


--
nosy: +taschini

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[Chris Rebert]

Chris Rebert  added the comment:

Here's a quick stab at 2/3rds of an implementation, and some docs.

--
Added file: http://bugs.python.org/file25310/shutil_open.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14644] test_logging failure on OS X Tiger

[Vinay Sajip]

Vinay Sajip  added the comment:

I've increased the SMTPHandler timeouts and the tests now seem to be passing, 
so I'll close this now.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14616] subprocess docs should mention pipes.quote/shlex.quote

[Tshepang Lekhonkhobe]

Changes by Tshepang Lekhonkhobe :


--
nosy: +tshepang

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14596] struct.unpack memory leak

[Robert Elsner]

Robert Elsner  added the comment:

Well then at least the docs need an update. I simply fail to see how a
cache memory leak constitutes "just fine" (while the caching behavior of
struct.unpack is not documented - if somebody wants caching, he ought to
use struct.Struct.unpack which does cache and does not leak). Something
like a warning: "struct.unpack might display memory leaks when parsing
big files using large format strings" might be sufficient. I do not like
the idea of code failing outside some not-documented "use-case".
Especially as those problems usually indicate some underlying design
flaw. I did not review the proposed patch but might find time to have a
look in a few months.

cheers

Am 20.04.2012 19:56, schrieb Mark Dickinson:
> 
> Mark Dickinson  added the comment:
> 
> IMO, the struct module does what it's intended to do just fine here.  I don't 
> a big need for any change.  I'd propose closing this as "won't fix".
> 
> --
> 
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[Hobs]

Hobs  added the comment:

Test passes on Ubuntu Oneiric Linux and 'open' action appropriately defaults to 
launching an editor for my particular OS settings.

Tests on Windows in work.

--
Added file: http://bugs.python.org/file25311/shutil_launch.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[Hobs]

Hobs  added the comment:

Implement shutil.launch() & fix minor shutil.disk_usage() doctext typo

Name changed from shutil.open to shutil.launch due to namespace conflict with 
open() builtin within the shutil module and for users that do

from shutil import *

On Ubuntu Oneiric Linux shutil.launch() doctest passes and `./python -m test 
-j3` doesn't change (OS-appropriate tests all pass).

Windows tests in work. Need Mac testing too.

--
Added file: http://bugs.python.org/file25312/shutil_open.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[Chris Rebert]

Chris Rebert  added the comment:

> # or os.name == 'mac' ???

Nope, that refers to retro Mac OS 9 (and probably lower). Mac OS X is 'posix' 
for os.name purposes.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[Chris Rebert]

Chris Rebert  added the comment:

`operation` seems questionable. IMO, the verbs seem stronger / more important 
than mere optional suggestions (particularly "open" vs. "edit" for files with 
read-only viewers), and only Windows supports them (so anyone requiring that 
feature might as well just use startfile() directly). By virtue of this 
function being cross-platform, we're kinda limited to just supporting the 
lowest common denominator.

Hobs, can you explain `gui`?

Also, does startfile() raise exceptions for either of the basic error 
conditions ("no such file" and "no associated application")? If not, I believe 
using the lower-level ShellExecute 
(http://msdn.microsoft.com/en-us/library/windows/desktop/bb762153%28v=vs.85%29.aspx
 ) or similar Windows API function would allow us to report such errors, as the 
other platform implementations currently do.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[Ram Rachum]

Changes by Ram Rachum :


--
nosy:  -cool-RR

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[R. David Murray]

Changes by R. David Murray :


--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14616] subprocess docs should mention pipes.quote/shlex.quote

[Chris Rebert]

Changes by Chris Rebert :


--
nosy: +cvrebert

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[R. David Murray]

R. David Murray  added the comment:

Is the error raising PEP 3151 compliant?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[Chris Rebert]

Chris Rebert  added the comment:

No, it isn't. Changing the `IOError(errno.ENOENT, "...`s to 
`FileNotFoundError("...`s would half fix it.

The other half, the `OSError(errno.ENOSYS)`s, has a FIXME for what's the right 
error to raise in that case ("no application associated with files of this 
type"). I have no idea myself. None of the new PEP 3151 errors apply. Nor did 
any of the errnos strictly speaking AFAICT; ENOSYS was the closest 
approximation I could find. Thoughts? Custom error class? Different errno? 
Something else?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> ENOSYS was the closest approximation I could find. Thoughts? Custom
> error class? Different errno? Something else?

Why not ValueError?

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14596] struct.unpack memory leak

[R. David Murray]

R. David Murray  added the comment:

Other of our functions that do caching have been fixed so that the cache does 
not grow unbounded (usually by using lrucache, I think).  IMO a cache that is 
unbounded by default is a bug.

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14596] struct.unpack memory leak

[Antoine Pitrou]

Antoine Pitrou  added the comment:

AFAIU, it's not unbounded, but it's the memory footprint of individual cached 
objects which can grow senseless.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14596] struct.unpack memory leak

[R. David Murray]

R. David Murray  added the comment:

If that is the case, then a doc footnote that a large repeat count will result 
in a large cache seems appropriate.  Some way to control the max size of the 
cache would also be a reasonable enhancement request, at which point the cache 
size issue could be documented along with the cache control.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14648] Attempt to format ascii and non-ascii strings together fails with "... UCS2 ..."

[Dmitry Dvoinikov]

New submission from Dmitry Dvoinikov :

Using Python 3.3.0a2 (default, Apr  1 2012, 19:34:58) [MSC v.1500 64 bit 
(AMD64)] on win32.

This line of code

"{0:s}{1:s}".format("ABC", "\u0410\u0411\u0412")

results in

SystemError: Cannot copy UCS2 characters into a string of ascii characters

--
components: Interpreter Core
messages: 159014
nosy: ddvoinikov
priority: normal
severity: normal
status: open
title: Attempt to format ascii and non-ascii strings together fails with "... 
UCS2 ..."
type: behavior
versions: Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14648] Attempt to format ascii and non-ascii strings together fails with "... UCS2 ..."

[R. David Murray]

R. David Murray  added the comment:

I get this result on a debug build of default on linux:

>>> "{0:s}{1:s}".format("ABC", "\u0410\u0411\u0412")
python: Objects/unicodeobject.c:1223: _copy_characters: Assertion `ch <= 
to_maxchar' failed.

--
nosy: +haypo, loewis, r.david.murray
priority: normal -> release blocker
stage:  -> needs patch
type: behavior -> crash

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1521950] shlex.split() does not tokenize like the shell

[Éric Araujo]

Éric Araujo  added the comment:

> I'd like to take a look at this (I wasn't aware of it before).
Are you interested in shlex in general or only this bug?  If the former, then 
I’ll try to remember to make you nosy on future issues.

BTW, what is the shlex unicode bug you mentioned a few times on Rietveld?  The 
one I know is fixed now.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13903] New shared-keys dictionary implementation

[Mark Shannon]

Changes by Mark Shannon :


Added file: http://bugs.python.org/file25313/73423916a242.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[Éric Araujo]

Éric Araujo  added the comment:

Thanks for relaunching this!

> I'm not sure I understand why this was moved to shutil.open. It seems 
> appropriate to try to accomplish what
> os.startfile() does in a cross-platform way. Don't many of the other os.* 
> calls do this--check os.name and
> then "do the right thing".
They don’t.  The os module is a thin wrapper on top of system functions.  
Cross-platform compat is not achieved with os.name checks but with 
platform-specific code in the C files.  As Windows provides a call named 
startfile, it is exposed.  When we want to provide a higher-level API on top of 
system calls, we use other modules such as shutil.

> fix minor shutil.disk_usage() doctext typo
Would you report this on another bug report or simply with a mail to the 
d...@python.org mailing list?  Thanks.

> Name changed from shutil.open to shutil.launch due to namespace conflict with 
> open() builtin within the shutil
> module and for users that do from shutil import *
I don’t think these are good arguments.  A lot of modules expose a function 
named open: tarfile, codecs, tokenize...  Python has namespaces, let’s use 
them.  The argument about import * is not strong either in my opinion, because 
all our docs recommend against this idiom.

One argument against open is that the other open functions I mention above 
return a file object, like the builtin open.  With this in mind I agree that a 
better name should be found.  I dislike launch though because it brings to my 
mind the idea of running/executing a program, not opening it in the appropriate 
program.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13903] New shared-keys dictionary implementation

[Mark Shannon]

Mark Shannon  added the comment:

I've updated the repository and uploaded a new patch in response to Benjamin's 
review. (And the contributor form is in the post).

One remaining issue is the return value of __sizeof__().
If it is an int, then it cannot accurately reflect the memory use,
but returning a float may seem rather surprising.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1521950] shlex.split() does not tokenize like the shell

[R. David Murray]

R. David Murray  added the comment:

I am interested in shell stuff in general.

The unicode bug is issue 1170.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[R. David Murray]

R. David Murray  added the comment:

Launch is far better than open for this, I think.  If someone can come up with 
an even better name, that would be good.  But I would not like to use open for 
this function, because it does not behave like other open functions.

The one exception I know of is webbrowser.  Webbrowser uses open, but the 
recommended way to call it is webbrowser.open(), which makes it clear you are 
opening it in the webbrowser (and opening the webbrowser if needed).  
shutil.open would convey no such connotation, to my mind.  (Only windows does 
extension based application opening from the *shell* as far as I know.)

Perhaps 'wmopen' (for Window Manager Open)?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10942] xml.etree.ElementTree.tostring returns type bytes, expected type str

[Gunnar Eikman]

Gunnar Eikman  added the comment:

I moved a working script from Ubuntu (Python 3.1.2) to Windows (Python 3.2.3) 
today.

Had to revise script. The tostring method returns a string on Linux 
(contradicts this issue), but bytes on Windows (as described in this issue)...

I used tostring with a single argument "tostring(theXml)"

Is there an explanation for this? I am not an advanced Python hacker...

Be careful when moving from one environment to another!

--
nosy: +Gunnar.Eikman

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14649] doctest.DocTestSuite error misleading when module has no docstrings

[Chris Jerdonek]

New submission from Chris Jerdonek :

When invoking doctest.DocTestSuite's constructor with a module that has no 
docstrings, doctest raises the following exception:

...
File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/doctest.py",
 line 2280, in DocTestSuite
raise ValueError(module, "has no tests")
ValueError: (, 'has no tests')

The error message is misleading because the exception is not raised for modules 
that have docstrings but no doctests, only for modules that have no docstrings.

To be accurate, the message should be something like 'has no docstrings'.

--
components: Library (Lib)
messages: 159022
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: doctest.DocTestSuite error misleading when module has no docstrings
type: behavior
versions: Python 2.7, Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14648] Attempt to format ascii and non-ascii strings together fails with "... UCS2 ..."

[Roundup Robot]

Roundup Robot  added the comment:

New changeset c7163a7f7cd2 by Benjamin Peterson in branch 'default':
inherit maxchar of field value where needed (closes #14648)
http://hg.python.org/cpython/rev/c7163a7f7cd2

--
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14648] Attempt to format ascii and non-ascii strings together fails with "... UCS2 ..."

[R. David Murray]

R. David Murray  added the comment:

A test needs to be added for this.

--
keywords: +easy
priority: release blocker -> normal
stage: committed/rejected -> test needed
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14648] Attempt to format ascii and non-ascii strings together fails with "... UCS2 ..."

[Benjamin Peterson]

Benjamin Peterson  added the comment:

What makes you think there isn't one?

--
nosy: +benjamin.peterson
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14648] Attempt to format ascii and non-ascii strings together fails with "... UCS2 ..."

[STINNER Victor]

STINNER Victor  added the comment:

> New changeset c7163a7f7cd2 by Benjamin Peterson in branch 'default':
> inherit maxchar of field value where needed (closes #14648)
> http://hg.python.org/cpython/rev/c7163a7f7cd2

The patch is wrong if the format only gets a substring instead of the
full string. I have a pending patch for this.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14648] Attempt to format ascii and non-ascii strings together fails with "... UCS2 ..."

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Ah, you are right.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13903] New shared-keys dictionary implementation

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 6e5855854a2e by Benjamin Peterson in branch 'default':
Implement PEP 412: Key-sharing dictionaries (closes #13903)
http://hg.python.org/cpython/rev/6e5855854a2e

--
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[Hobs]

Hobs  added the comment:

Does no one like "os.startfile" as a home for this? Besides myself and the
original 2008 proposer, of course. Can anyone explain to us newbies why
it's a bad idea to have the cross-platform module do things identically
across platforms?

@David,

`shutils.wmopen` locks you into never implementing the shell application
launching option (`gui`=False in my crude implementation) that so many
projects need. Each project currently implements it in their own
nonstandard way (e.g. Mercurial and Bazaar), sometimes with not so `nice`
consequences.

You're right that only launching from Linux/Mac shell requires manual
selection of an app, but that's exactly the inconvenience that I was hoping
to solve. Many Ubuntu GUI apps use extensions and MIME-types (associated
with extensions) to recognize their files rather than probing magic
headers. Why shouldn't their shell apps be allowed a standard way to do the
same?

If I implemented *exactly* os.startfile() functionality across the 3 major
platforms, would that be enough to interest the community in an
os.startfile() refinement rather than a new shutils.launch()? I'd drop the
distracting `gui` option to make it completely identical, if that helps.
Or, if the community preferred I could *add* the `gui` option to
startfile() across the board so that even Windows users could have the
option of choosing to edit a file within their shell (if they've installed
such an editor, of course).

@Chris,

Thanks for the tip on where to find low level exception information in
Windows. Sounds like a good idea to try to be as identical to
os.startfile() as possible. But that's why I thought the `operation` option
would be attractive to the community.

I'll test on windows (unless someone else chimes in with Windows
experience) and see what I can learn about exceptions and what it would
take to make os.startfile() truly OS-agnostic, all the way down to each
exception raised.

`gui` allows the user to chose to launch a shell-based text editor (emacs,
vi/vim, nano, $EDITOR, based on user settings). It standardizes what bzr,
hg and other popular cross-platform python projects that launch shell
editors do already.

On Mon, Apr 23, 2012 at 10:12 PM, R. David Murray wrote:

>
> R. David Murray  added the comment:
>
> Launch is far better than open for this, I think.  If someone can come up
> with an even better name, that would be good.  But I would not like to use
> open for this function, because it does not behave like other open
> functions.
>
> The one exception I know of is webbrowser.  Webbrowser uses open, but the
> recommended way to call it is webbrowser.open(), which makes it clear you
> are opening it in the webbrowser (and opening the webbrowser if needed).
>  shutil.open would convey no such connotation, to my mind.  (Only windows
> does extension based application opening from the *shell* as far as I know.)
>
> Perhaps 'wmopen' (for Window Manager Open)?
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[Éric Araujo]

Éric Araujo  added the comment:

Please trust us that this is our policy.  os is a thin wrapper only.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13903] New shared-keys dictionary implementation

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Okay. I committed the latest patch. Subtleties like __sizeof__ can be worked 
out as people start using it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14648] Attempt to format ascii and non-ascii strings together fails with "... UCS2 ..."

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
resolution: fixed -> 
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13903] New shared-keys dictionary implementation

[Yury Selivanov]

Yury Selivanov  added the comment:

Mark, did you add the test that your patch initially was failing with? 
http://mail.python.org/pipermail/python-dev/2012-February/116605.html

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14648] Attempt to format ascii and non-ascii strings together fails with "... UCS2 ..."

[R. David Murray]

R. David Murray  added the comment:

> What makes you think there isn't one?

Poor eyesight?  Sorry.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[Hobs]

Hobs  added the comment:

@Éric

Thanks for clearing up my misunderstanding of os and shutil. I get it now.

I'm sure you know this, and it's clear you agree with changing the name,
but just to add fire to your resolve, the difference between shutil.open()
and the other `*.open()` modules you mention is that most of the others
began their life with `open()` in their namespace (I think). A new `open()`
in shutil, this late in its life, would break a *lot* of old code,
sometimes invisibly. Apps might launch invisibly on servers with X-windows
configured to display remotely, fail to raise exceptions, and leave a lot
of admins dumbfounded and cursing the python standard library migration.
Seems like pretty draconian punishment for bad (but not forbidden or
deprecated) idioms. I'd rather not have my code be one of the rocks in that
stoning. A few would surely fly my way.

On Mon, Apr 23, 2012 at 9:58 PM, Éric Araujo  wrote:

>
> Éric Araujo  added the comment:
>
> Thanks for relaunching this!
>
> > I'm not sure I understand why this was moved to shutil.open. It seems
> appropriate to try to accomplish what
> > os.startfile() does in a cross-platform way. Don't many of the other
> os.* calls do this--check os.name and
> > then "do the right thing".
> They don’t.  The os module is a thin wrapper on top of system functions.
>  Cross-platform compat is not achieved with os.name checks but with
> platform-specific code in the C files.  As Windows provides a call named
> startfile, it is exposed.  When we want to provide a higher-level API on
> top of system calls, we use other modules such as shutil.
>
> > fix minor shutil.disk_usage() doctext typo
> Would you report this on another bug report or simply with a mail to the
> d...@python.org mailing list?  Thanks.
>
> > Name changed from shutil.open to shutil.launch due to namespace conflict
> with open() builtin within the shutil
> > module and for users that do from shutil import *
> I don’t think these are good arguments.  A lot of modules expose a
> function named open: tarfile, codecs, tokenize...  Python has namespaces,
> let’s use them.  The argument about import * is not strong either in my
> opinion, because all our docs recommend against this idiom.
>
> One argument against open is that the other open functions I mention above
> return a file object, like the builtin open.  With this in mind I agree
> that a better name should be found.  I dislike launch though because it
> brings to my mind the idea of running/executing a program, not opening it
> in the appropriate program.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14650] 1-character typo in shutils doctext

[Hobs]

New submission from Hobs :

This patch fixes a 1-character typo in the docstring for shutil.disk_usage().

--
assignee: docs@python
components: Documentation
files: shutil_disk_usage_doc.patch
keywords: patch
messages: 159035
nosy: Hobson.Lane, docs@python, eric.araujo
priority: normal
severity: normal
status: open
title: 1-character typo in shutils doctext
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25314/shutil_disk_usage_doc.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13684] httplib tunnel infinite loop

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 790ae45b52be by Senthil Kumaran in branch '2.7':
Fix for Issue13684 - httplib tunnel infinite loop
http://hg.python.org/cpython/rev/790ae45b52be

New changeset 7787a9aebdc6 by Senthil Kumaran in branch '3.2':
3.2 - Fix for Issue13684 - httplib tunnel infinite loop
http://hg.python.org/cpython/rev/7787a9aebdc6

New changeset f98fb46ff273 by Senthil Kumaran in branch '2.7':
news for issue13684
http://hg.python.org/cpython/rev/f98fb46ff273

New changeset 26631c56d81f by Senthil Kumaran in branch '3.2':
news for issue13684
http://hg.python.org/cpython/rev/26631c56d81f

New changeset 1acb252a3858 by Senthil Kumaran in branch 'default':
3.2 - Fix for Issue13684 - httplib tunnel infinite loop
http://hg.python.org/cpython/rev/1acb252a3858

New changeset 246abd64e830 by Senthil Kumaran in branch 'default':
news for issue13684
http://hg.python.org/cpython/rev/246abd64e830

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[Hobs]

Hobs  added the comment:

New patch incorporates improvements from pitrou, cvrebert, r.david.murray, 
eric.araujo, cool-RR

--
Added file: http://bugs.python.org/file25315/shutil_open.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[R. David Murray]

R. David Murray  added the comment:

Initially this issue was about implementing a startfile-equivalent on posix.  
But if you have to add a gui option to startfile to not lanuch a GUI, and your 
real goal is a consistent way to launch non-gui programs on posix, then I don't 
see that this is about implementing startfile, and the enhancement should 
*definitely* not go in os.

Setting that aside for a moment, let me say something about the wrapper 
argument.  There *is* a lot of compatibility code in os.  We do have to jump 
through hoops to get posix equivalent functionality on Windows.  So doing the 
reverse to get windows-equivalent functionality on posix would seem fair 
turnabout.

However, it is also true that those hoops we jump through for windows involve 
calling Windows APIs (the equivalent of the posix system calls we are 
wrapping).  So while the hoops aren't necessarily all that "thin", they are 
wrappers around APIs at the OS level (thus the name of the module).  In this 
case the hoops are not system calls.  So even disregarding my initial comments 
above, while I don't think the argument is quite as clear cut as Éric does, I 
do think in this case the code, which is *not* operating at the C API level, 
does not belong in OS.

Finally, I'm still against shutil.open as the name.  It does not suggest to me 
that an application is being run.  (Neither does 'startfile', by the way).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[Sven Marnach]

Sven Marnach  added the comment:

The semantics of "associated application" change considerably from operating 
system to operating system.  As an example, ``os.startfile("a.py")`` will 
usually run `a.py` in the Python interpreter, while ``xdg-open a.py`` it will 
usually open the source code in an editor on Linux.  This might reduce the 
overall usefulness of the proposed ``shutil.launch()`` function.

--
nosy: +smarnach

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14651] `pysetup run [cmd]` can't handle option values in the setup.cfg

[Takayuki SHIMIZUKAWA]

New submission from Takayuki SHIMIZUKAWA :

`pysetup run [cmd]` can't handle option values in the setup.cfg

setup.cfg::

  [sdist]
  formats = gztar
  dist-dir = _dist

run on windows::

  C:> pysetup run sdist

That command generate `dist/package-version.zip` instead of 
`_dist/packcage-version.tar.gz`.

attached patch will fix it.

--
assignee: eric.araujo
components: Distutils2
files: use-setupcfg-options-r13146.patch
keywords: patch
messages: 159040
nosy: alexis, eric.araujo, shimizukawa, tarek
priority: normal
severity: normal
status: open
title: `pysetup run [cmd]` can't handle option values in the setup.cfg
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file25316/use-setupcfg-options-r13146.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14650] 1-character typo in shutil docstring

[Éric Araujo]

Éric Araujo  added the comment:

Thanks.  Can you check if the typo is also present in the documentation (i.e. 
in Doc/library)?

--
title: 1-character typo in shutils doctext -> 1-character typo in shutil 
docstring

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14651] pysetup run cmd can't handle option values in the setup.cfg

[Éric Araujo]

Éric Araujo  added the comment:

Thanks for the report.  This is weird, given that the code for setting command 
options in setup.cfg directly comes from distutils and works there.  I think 
that this error may come from another bug in pysetup (i.e. in distutils2.run) 
where the config file is parsed too late; I discovered that bug a week ago and 
did not find the time to apply the fix.  I’ll keep you updated on this.

--
title: `pysetup run [cmd]` can't handle option values in the setup.cfg -> 
pysetup run cmd can't handle option values in the setup.cfg
versions: +3rd party, Python 3.3 -Python 2.6, Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[Éric Araujo]

Éric Araujo  added the comment:

> The semantics of "associated application" change considerably from
> operating system to operating system.  As an example,
> ``os.startfile("a.py")`` will usually run `a.py` in the Python
> interpreter, while ``xdg-open a.py`` it will usually open the source
> code in an editor on Linux.

Outch.  I think the behavior should be more similar than that, i.e. that the 
function should use startfile with the edit action on Windows.

About the name: I thought about “edit”; it really means open_file_in_editor.  
BTW shutil feels the wrong place for this but I don’t think we have anything 
better.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[Hobs]

Hobs  added the comment:

Last patch was invalid and untested.

New patch passes `make patchtest`, but still doing the full test suite on 
Windows and Linux.

Still unsure if I raised the right exceptions with the right arguments.

--
Added file: http://bugs.python.org/file25317/shutil_open.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14635] telnetlib uses select instead of poll - limited to FD_SETSIZE fds

[R. David Murray]

R. David Murray  added the comment:

Éric: there are devices that still only allow telnet.  Older cisco routers 
(*many* of which are still in the field) are just one example I'm familiar 
with.  I don't currently have any tools that use telnetlib to talk to them, but 
I've got at least two I'd like to find time to write...and I can easily imagine 
this limitation coming up as a real issue at Google :)

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14632] Race condition in WatchedFileHandler leads to unhandled exception

[Charles-François Natali]

Charles-François Natali  added the comment:

> Charles-François: Certainly I can reduce the iterations to make the test
> faster. As it is, I did reproduce the failure on my dev system, but only
> once, after running John's test script about a dozen times: every other
> time, it completed successfully :-(

Juste reduce the sleep times, e.g.:
"""
@@ -17,7 +17,7 @@
 os.unlink(fname)
 except OSError:
 pass
-stime = 0.04 * random.randint(0, 4)
+stime = 0.004 * random.randint(0, 4)
 time.sleep(stime)

@@ -50,7 +50,7 @@
 log.setLevel(logging.INFO)

 for ii in range(LOGCOUNT):
-stime = 0.05 # * random.randint(0, 4)
+stime = 0.005 # * random.randint(0, 4)
 time.sleep(stime)
 log.warning('Foo bar %d', ii)
"""

With this change, I can trigger a failure reliably in around 1s, and
my computer is rather slow.

> Isn't it simpler if I just replace the os.path.exists() calls with
> os.stat(), and check for ENOENT if an exception of type OSError or
> WindowsError occurs?

The problem is that it would leave a race window if the file is
changed between the time it's opened (I guess in
logging.FileHandler.__init__()) and the first call to stat().
John's patch is safe in this regard, thanks to fstat().

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14638] pydoc error on instance of a custom class

[R. David Murray]

Changes by R. David Murray :


--
assignee:  -> r.david.murray
nosy: +r.david.murray
stage:  -> commit review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14638] pydoc error on instance of a custom class

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 2a35dfbe3d99 by R David Murray in branch '3.2':
#14638: pydoc now treats non-str __name__ as None instead of raising
http://hg.python.org/cpython/rev/2a35dfbe3d99

New changeset 86b4b54bb0fa by R David Murray in branch 'default':
merge #14638: pydoc now treats non-str __name__ as None instead of raising
http://hg.python.org/cpython/rev/86b4b54bb0fa

New changeset 501651b93cb0 by R David Murray in branch '2.7':
#14638: pydoc now treats non-str __name__ as None instead of raising
http://hg.python.org/cpython/rev/501651b93cb0

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14638] pydoc error on instance of a custom class

[R. David Murray]

R. David Murray  added the comment:

Thanks Peter.

--
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13903] New shared-keys dictionary implementation

[Mark Shannon]

Mark Shannon  added the comment:

I fixed it back then, but didn't add the test.
It subsequently regressed.
Should know better.

Patch (with test this time) attached.

--
resolution: fixed -> 
status: closed -> open
Added file: http://bugs.python.org/file25318/str_subclass.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10731] UnicodeDecodeError in OS X tkinter when binding to

[Ned Deily]

Ned Deily  added the comment:

A potential fix has been generated for Tk.  I'll close this issue once the fix 
has been verified with _tkinter.

--
resolution:  -> out of date
stage: needs patch -> 
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[Hobs]

Hobs  added the comment:

I'll be happy to code, test, and use the new .() function wherever it 
ends up and whatever it is named... but...

> Initially this issue was about implementing a startfile-equivalent on
> posix.  But if you have to add a gui option to startfile to not lanuch > a 
> GUI, and your real goal is a consistent way to launch non-gui 
> programs on posix

Actually, my real goal was a consistent way of launching any editor or viewer 
(or even interpreter) on any platform with graceful fallback from the caller's 
preferred action to the others. I wanted my application that called the new 
idiomatic standard library function to do something  smarter (in my mind) than 
what OSes do by default and more consistent and robust than what hg and bzr do 
by design. Perhaps the fallback should only be within the read/write/execute 
"silos", but that should be configurable as well, defaulting to do the safe 
thing (fallback within editors or within viewers only).

GUI viewer (IE, then Firefox, then Chrome, then Safari)
GUI editor (notepad, then ...)
shell editor ($EDITOR, then vim, then vi, then nano, etc)
shell viewer (less, then more, then cat)

Obviously this isn't feasible. At least not for my first patch.

--
Added file: http://bugs.python.org/file25319/shutil_open.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14641] Minor fixes in sockets.rst

[Roundup Robot]

Roundup Robot  added the comment:

New changeset f24d8dc1a986 by Sandro Tosi in branch '2.7':
Issue #14641: minor fixes to sockets Howto; patch by Dionysios Kalofonos
http://hg.python.org/cpython/rev/f24d8dc1a986

New changeset 9bb9604519ce by Sandro Tosi in branch '3.2':
Issue #14641: minor fixes to sockets Howto; patch by Dionysios Kalofonos
http://hg.python.org/cpython/rev/9bb9604519ce

New changeset caf39de79819 by Sandro Tosi in branch 'default':
Issue #14641: merge with 3.2
http://hg.python.org/cpython/rev/caf39de79819

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14652] Better error messages for wsgiref validator failures

[Sidney San Martín]

New submission from Sidney San Martín :

wsgiref’s validation middleware is missing messages for many of its assertions, 
and its docstring doesn’t reflect read() now requiring an argument (said that 
it took an optional argument).

Here’s a patch to add some and update the comment.

--
components: Library (Lib)
files: ssm_validate.patch
keywords: patch
messages: 159053
nosy: ssm
priority: normal
severity: normal
status: open
title: Better error messages for wsgiref validator failures
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25320/ssm_validate.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14641] Minor fixes in sockets.rst

[Sandro Tosi]

Sandro Tosi  added the comment:

Thanks for your contribution!

--
nosy: +sandro.tosi
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13903] New shared-keys dictionary implementation

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 34b6998efd2c by Benjamin Peterson in branch 'default':
fix instance dicts with str subclasses (#13903)
http://hg.python.org/cpython/rev/34b6998efd2c

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[Chris Rebert]

Chris Rebert  added the comment:

>> ENOSYS was the closest approximation I could find. Thoughts? Custom
>> error class? Different errno? Something else?
>
> Why not ValueError?

Because the value they provided was perfectly valid (the file/directory *did* 
exist), so the caller's request was reasonable. It's the system(/ its (lack of) 
configuration) that failed the caller in finding an opener application. The 
"fix" after encountering the exception is to add an association to the system 
configuration (and/or install a new application), not to pass a different path 
to the function.

IMO, it feels like an EnvironmentError or RuntimeError of some sort; hence the 
current use of OSError.
(Or NotImplementedError, but we're already using that exception to indicate a 
different failure condition, so that's out.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14650] 1-character typo in shutil docstring

[Hobs]

Hobs  added the comment:

Eric, the documentation (shutil.rst) looks fine. Just a code comment typo.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[Chris Rebert]

Chris Rebert  added the comment:

Hobs, why is exit code 4 of xdg-open (which the manpage describes as the 
extremely generic "The action failed.") interpreted as FileNotFoundError in 
your new version?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[Hobs]

Hobs  added the comment:

Because that's how I caused the exception in
Ubuntu--shutil.launch('file_that_doesnt_exist'). That's why I changed the
message to "file may not exist" for both 2 and 4, but should probably prove
that 2 sometimes happens when the file does exist (like with permission or
visiblity/hidden errors in some OSes).

Interestingly I got it to quietly, insidiously fail on Ubuntu by passing it
a path to an empty file named empty.exe with the executeable bit set (but
permissions and executable bit didn't seem to make a difference). No app
was launched (or too quickly disappeared for me to see) and shutil.launch()
did not complain.

On Tue, Apr 24, 2012 at 1:58 AM, Chris Rebert wrote:

>
> Chris Rebert  added the comment:
>
> Hobs, why is exit code 4 of xdg-open (which the manpage describes as the
> extremely generic "The action failed.") interpreted as FileNotFoundError in
> your new version?
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14650] 1-character typo in shutil docstring

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 629d4c2faa87 by Sandro Tosi in branch 'default':
Issue #14650: fix typo in shutil.disk_usage() docstring; patch by Hobson Lane
http://hg.python.org/cpython/rev/629d4c2faa87

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14650] 1-character typo in shutil docstring

[Sandro Tosi]

Sandro Tosi  added the comment:

Thanks for your contribution!

--
nosy: +sandro.tosi
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[Chris Rebert]

Chris Rebert  added the comment:

Also:

The FileNotFoundErrors quote the path twice:
Python 2.7.1 (r271:86832, Jul 31 2011, 19:30:53) 
>>> path = "/foo/bar"
>>> print "Path '%s' may not exist" % repr(path)
Path ''/foo/bar'' may not exist

The ValueError error message isn't grammatically correct and doesn't account 
for the possibility that the path is a directory (consider the case of a Unix 
system where the GUI file manager has been uninstalled; directories would then 
fail to open). May I suggest my original message?: "No application is 
associated with files/directories of the given type"

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[Chris Rebert]

Chris Rebert  added the comment:

The xdg-open source code 
(http://cgit.freedesktop.org/xdg/xdg-utils/tree/scripts/xdg-open ) shows that 
exit code 4 is used whenever an invocation of another opener script (e.g. 
kde-open, gnome-open) fails for any reason besides said script not being 
installed. So I'm not so sure we can jump to the conclusion that 4 
automatically means FileNotFound.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[Hobs]

Hobs  added the comment:

Yea, I hosed up the path quoting in a misguided attempt at shortening for
80-col line-wrapping. Yours is better, will revert.

On Tue, Apr 24, 2012 at 2:09 AM, Chris Rebert wrote:

>
> Chris Rebert  added the comment:
>
> Also:
>
> The FileNotFoundErrors quote the path twice:
>Python 2.7.1 (r271:86832, Jul 31 2011, 19:30:53)
>>>> path = "/foo/bar"
>>>> print "Path '%s' may not exist" % repr(path)
>Path ''/foo/bar'' may not exist
>
> The ValueError error message isn't grammatically correct and doesn't
> account for the possibility that the path is a directory (consider the case
> of a Unix system where the GUI file manager has been uninstalled;
> directories would then fail to open). May I suggest my original message?:
> "No application is associated with files/directories of the given type"
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[Chris Rebert]

Chris Rebert  added the comment:

>> The semantics of "associated application" change considerably from
>> operating system to operating system.  As an example,
>> ``os.startfile("a.py")`` will usually run `a.py` in the Python
>> interpreter, while ``xdg-open a.py`` it will usually open the source
>> code in an editor on Linux.
>
> Outch.  I think the behavior should be more similar than that, i.e. that the 
> function should use startfile with the edit action on Windows.

It's a universal problem on all 3 platforms. Given a script file argument, a 
generic "open" (as opposed to "edit") procedure will either run the script or 
open it in an editor, depending entirely upon the user's system configuration. 
Same thing happens when double-clicking a script in the file manager, which is 
IMO what we're trying to emulate here.

It sounds like some people want a generic "(text) edit" procedure, which IMO is 
different enough to warrant a separate bug since there are different/more 
design issues to tackle (e.g. if someone edit()s an image file (or a file of 
uncertain type) on Unix, what application is opened, and how is that 
determined?). And no peeking at Mercurial's code; it's under GPLv2, whereas 
Python is under BSD/MIT-like licensing, making them incompatible.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14640] Typos in pyporting.rst

[Roundup Robot]

Roundup Robot  added the comment:

New changeset f7b002e5cac7 by R David Murray in branch '3.2':
#14640: Fix typos/syntax in pyporting.rst.
http://hg.python.org/cpython/rev/f7b002e5cac7

New changeset 13c30fe3f427 by R David Murray in branch 'default':
Merge #14640: Fix typos/syntax in pyporting.rst.
http://hg.python.org/cpython/rev/13c30fe3f427

New changeset 758f5585ce52 by R David Murray in branch '2.7':
#14640: Fix typos/syntax in pyporting.rst.
http://hg.python.org/cpython/rev/758f5585ce52

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14640] Typos in pyporting.rst

[R. David Murray]

R. David Murray  added the comment:

Thanks, Dionysios.

--
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior
versions: +Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[R. David Murray]

R. David Murray  added the comment:

I'm not a lawyer (duh), but my understanding is that *looking* at GPL code (as 
opposed to proprietary code, where someone might sue you about it and not 
looking is a good defense) is OK, you just can't copy it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I'm not a lawyer (duh), but my understanding is that *looking* at GPL
> code (as opposed to proprietary code, where someone might sue you
> about it and not looking is a good defense) is OK, you just can't copy
> it.

You could probably copy a one- or two-liner, especially if it's not a
very creative one.
By that I mean that putting "i = i + 1" under the GPL is not enough to
prevent anyone else to write the same line of code :-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14632] Race condition in WatchedFileHandler leads to unhandled exception

[Vinay Sajip]

Vinay Sajip  added the comment:

[snip]
>With this change, I can trigger a failure reliably in around 1s, and
>my computer is rather slow.

I'm working in a VM, and although I can get John's script to fail more 
regularly (with the reduced timeouts and counts of 1000), a version of the test 
which I added to test_logging always succeeds. That code is:

    @unittest.skipUnless(threading, 'Threading required for this test.')
    def test_race(self):
        # Issue #14632 refers.
        def remove_loop(fname, tries):
            for _ in range(tries):
                try:
                    os.unlink(fname)
                except OSError:
                    pass
                time.sleep(0.004 * random.randint(0, 4))

        def cleanup(remover, fn, handler):
            handler.close()
            remover.join()
            if os.path.exists(fn):
                os.unlink(fn)

        fd, fn = tempfile.mkstemp('.log', 'test_logging-3-')
        os.close(fd)
        del_count = 1000
        log_count = 1000
        remover = threading.Thread(target=remove_loop, args=(fn, del_count))
        remover.daemon = True
        remover.start()
        h = logging.handlers.WatchedFileHandler(fn)
        self.addCleanup(cleanup, remover, fn, h)
        f = logging.Formatter('%(asctime)s: %(levelname)s: %(message)s')
        h.setFormatter(f)
        for _ in range(log_count):
            time.sleep(0.005)
            r = logging.makeLogRecord({'msg': 'testing' })
            h.handle(r)

I can't see why this always works, while John's script sometimes fails.
>The problem is that it would leave a race window if the file is
>changed between the time it's opened (I guess in
>logging.FileHandler.__init__()) and the first call to stat().
>John's patch is safe in this regard, thanks to fstat().

Oh, right - missed that.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

Any thougts?  Is a 60% performance increase for the common case of acquiring an 
uncontested lock worth doing?

Btw, for our console game I also opted for non-semaphore based locks in 
thread_pthread.h, because our console profilers were alarmed at all the kernel 
transitions caused by the GIL being ticked

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Is a 60% performance increase for the common case of acquiring an
> uncontested lock worth doing?

Yes, I agree it is. However, the Vista-specific path seems uninteresting, if 
it's really 2% faster.

> our console profilers were alarmed at all the kernel transitions caused 
> by the GIL being ticked

That's the old GIL. The new GIL uses a fixed timeout with a condition variable.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14610] configure script hangs on pthread verification and PTHREAD_SCOPE_SYSTEM verification on Ubuntu

[Raphael Cruzeiro]

Raphael Cruzeiro  added the comment:

Here is the output of sh -x ./configure

--
Added file: http://bugs.python.org/file25321/output_sh

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14653] Improve mktime_tz to use calendar.timegm instead of time.mktime

[Mitar]

New submission from Mitar :

I would suggest improvement of mktime_tz to use calendar.timegm internally 
instead of time.mktime. The problem is that on Windows mktime_tz fails with 
"mktime argument out of range" for this code:

mktime_tz(parsedate_tz('Thu, 1 Jan 1970 00:00:00 GMT'))

if user is in GMT+X timezone. Obviously, "Thu, 1 Jan 1970 00:00:00 GMT" is not 
out of range. But because mktime_tz uses internally time.mktime which takes 
into the account local time (and local timezone) and then compensate for the 
timeline, out of range condition happens. I would suggest such implementation:

def mktime_tz(data):
"""Turn a 10-tuple as returned by parsedate_tz() into a UTC timestamp."""
if data[9] is None:
# No zone info, so localtime is better assumption than GMT
return time.mktime(data[:8] + (-1,))
else:
t = calendar.timegm(data[:8] + (0,))
return t - data[9]

It does not raise and exception, and it is also much cleaner: directly using 
GMT function and not localtime with timezone compensation.

--
components: Library (Lib)
messages: 159074
nosy: mitar
priority: normal
severity: normal
status: open
title: Improve mktime_tz to use calendar.timegm instead of time.mktime
type: behavior
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14610] configure script hangs on pthread verification and PTHREAD_SCOPE_SYSTEM verification on Ubuntu

[Raphael Cruzeiro]

Raphael Cruzeiro  added the comment:

Posting the strac output

--
Added file: http://bugs.python.org/file25322/strace.output.txt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14339] Optimizing bin, oct and hex

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I can only do this tomorrow.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14624] Faster utf-16 decoder

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Here are the results of benchmarking (numbers in MB/s).

On 32-bit Linux, AMD Athlon 64 X2 4600+ @ 2.4GHz:

  Py2.7Py3.2Py3.3   
patch

utf-16le  'A'*1   504 (+282%)  1905 (+1%)   565 (+241%) 
 1927
utf-16le  '\x80'*1503 (+264%)  1894 (-3%)   417 (+340%) 
 1833
utf-16le'\x80'+'A'*   504 (+264%)  1890 (-3%)   422 (+335%) 
 1834
utf-16le  '\u0100'*1  503 (+249%)  1896 (-7%)   357 (+391%) 
 1754
utf-16le'\u0100'+'A'* 504 (+252%)  1896 (-6%)   360 (+393%) 
 1776
utf-16le'\u0100'+'\x80'*  503 (+249%)  1890 (-7%)   357 (+392%) 
 1756
utf-16le  '\u8000'*1  503 (-18%)   355 (+16%)   75 (+449%)  
 412
utf-16le'\u8000'+'A'* 504 (+254%)  1892 (-6%)   359 (+397%) 
 1783
utf-16le'\u8000'+'\x80'*  503 (+249%)  1896 (-7%)   357 (+392%) 
 1755
utf-16le'\u8000'+'\u0100'*503 (+258%)  1901 (-5%)   359 (+402%) 
 1802
utf-16le  '\U0001'*1  484 (-14%)   379 (+9%)103 (+303%) 
 415
utf-16le'\U0001'+'A'* 504 (+244%)  1905 (-9%)   353 (+392%) 
 1735
utf-16le'\U0001'+'\x80'*  503 (+245%)  1899 (-9%)   348 (+398%) 
 1733
utf-16le'\U0001'+'\u0100'*503 (+244%)  1882 (-8%)   348 (+397%) 
 1729
utf-16le'\U0001'+'\u8000'*503 (-18%)   355 (+16%)   71 (+482%)  
 413

utf-16be  'A'*1   504 (+284%)  1553 (+24%)  469 (+312%) 
 1933
utf-16be  '\x80'*1504 (+251%)  1551 (+14%)  387 (+357%) 
 1770
utf-16be'\x80'+'A'*   504 (+261%)  1549 (+17%)  386 (+371%) 
 1819
utf-16be  '\u0100'*1  503 (+175%)  1544 (-10%)  333 (+316%) 
 1384
utf-16be'\u0100'+'A'* 505 (+178%)  1548 (-9%)   335 (+319%) 
 1403
utf-16be'\u0100'+'\x80'*  503 (+179%)  1552 (-9%)   336 (+318%) 
 1405
utf-16be  '\u8000'*1  503 (-2%)415 (+19%)   75 (+559%)  
 494
utf-16be'\u8000'+'A'* 504 (+179%)  1551 (-9%)   335 (+320%) 
 1408
utf-16be'\u8000'+'\x80'*  504 (+178%)  1551 (-10%)  336 (+317%) 
 1402
utf-16be'\u8000'+'\u0100'*504 (+179%)  1549 (-9%)   336 (+318%) 
 1404
utf-16be  '\U0001'*1  483 (-7%)407 (+10%)   105 (+326%) 
 447
utf-16be'\U0001'+'A'* 504 (+149%)  1554 (-19%)  317 (+295%) 
 1253
utf-16be'\U0001'+'\x80'*  503 (+153%)  1543 (-17%)  317 (+302%) 
 1275
utf-16be'\U0001'+'\u0100'*503 (+153%)  1537 (-17%)  317 (+302%) 
 1274
utf-16be'\U0001'+'\u8000'*503 (-2%)415 (+19%)   71 (+597%)  
 495

On 32-bit Linux, Intel Atom N570 @ 1.66GHz:

  Py2.7Py3.2Py3.3   
patch

utf-16le  'A'*1   136 (+417%)  584 (+20%)   184 (+282%) 
 703
utf-16le  '\x80'*1136 (+392%)  580 (+15%)   160 (+318%) 
 669
utf-16le'\x80'+'A'*   136 (+398%)  582 (+16%)   159 (+326%) 
 677
utf-16le  '\u0100'*1  137 (+346%)  583 (+5%)129 (+374%) 
 611
utf-16le'\u0100'+'A'* 136 (+358%)  582 (+7%)129 (+383%) 
 623
utf-16le'\u0100'+'\x80'*  136 (+348%)  580 (+5%)129 (+372%) 
 609
utf-16le  '\u8000'*1  136 (+18%)   127 (+27%)   38 (+324%)  
 161
utf-16le'\u8000'+'A'* 136 (+357%)  582 (+7%)129 (+382%) 
 622
utf-16le'\u8000'+'\x80'*  136 (+351%)  581 (+6%)128 (+380%) 
 614
utf-16le'\u8000'+'\u0100'*136 (+349%)  581 (+5%)129 (+374%) 
 611
utf-16le  '\U0001'*1  153 (-3%)140 (+6%)53 (+181%)  
 149
utf-16le'\U0001'+'A'* 136 (+296%)  581 (-7%)131 (+311%) 
 538
utf-16le'\U0001'+'\x80'*  136 (+289%)  584 (-9%)131 (+304%) 
 529
utf-16le'\U0001'+'\u0100'*136 (+290%)  579 (-8%)130 (+308%) 
 530
utf-16le'\U0001'+'\u8000'*136 (+25%)   128 (+33%)   38 (+347%)  
 170

utf-16be  'A'*1   136 (+331%)  441 (+33%)   166 (+253%) 
 586
utf-16be  '\x80'*1136 (+309%)  440 (+26%)   145 (+283%) 
 556
utf-16be'\x80'+'A'*   136 (+312%)  442 (+27%)   145 (+286%) 
 560
utf-16be  '\u0100'*1  136 (+231%)  441 (+2%)120 (+275%) 
 450
utf-16be'\u0100'+'A'* 136 (+232%)  442 (+2%)120 (+276%) 
 451
utf-16be'\u0100'+'\x80'*  136 (+231%)  438 (+3%)119 (+278%) 
 450
utf-16be  '\u8000'*1  136 (+22%)   127 (+31%)   38 (+337%)  
 166
utf-16be'\u8000'+'A'* 136 (+232%)  439 (+3%)120 (+276%) 
 451
utf-16be'\u8000'+'\x80'*  136 

[issue14625] Faster utf-32 decoder

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Here are the results of benchmarking (numbers in MB/s).

On 32-bit Linux, AMD Athlon 64 X2 4600+ @ 2.4GHz:

  Py2.7 Py3.2 Py3.3 
patchA   patchB

utf-32le  'A'*1   461 (+215%)   454 (+220%)   292 
(+398%)   1213 (+20%)   1454
utf-32le  '\x80'*1458 (+177%)   454 (+180%)   271 
(+369%)   1124 (+13%)   1270
utf-32le'\x80'+'A'*   462 (+171%)   454 (+175%)   271 
(+361%)    (+13%)   1250
utf-32le  '\u0100'*1  457 (+133%)   454 (+135%)   220 
(+385%)   1002 (+6%)1067
utf-32le'\u0100'+'A'* 461 (+129%)   454 (+132%)   220 
(+379%)   993 (+6%) 1054
utf-32le'\u0100'+'\x80'*  458 (+131%)   454 (+133%)   220 
(+381%)   1002 (+6%)1059
utf-32le  '\u8000'*1  457 (+133%)   454 (+135%)   220 
(+385%)   1002 (+6%)1066
utf-32le'\u8000'+'A'* 462 (+128%)   454 (+132%)   220 
(+379%)   994 (+6%) 1053
utf-32le'\u8000'+'\x80'*  457 (+132%)   454 (+134%)   220 
(+382%)   1000 (+6%)1061
utf-32le'\u8000'+'\u0100'*457 (+132%)   454 (+134%)   220 
(+382%)   1002 (+6%)1061
utf-32le  '\U0001'*1  386 (+167%)   416 (+148%)   212 
(+386%)   930 (+11%)1031
utf-32le'\U0001'+'A'* 461 (+126%)   415 (+152%)   222 
(+370%)   940 (+11%)1044
utf-32le'\U0001'+'\x80'*  458 (+125%)   415 (+148%)   222 
(+364%)   930 (+11%)1031
utf-32le'\U0001'+'\u0100'*458 (+125%)   415 (+148%)   212 
(+386%)   930 (+11%)1031
utf-32le'\U0001'+'\u8000'*458 (+125%)   415 (+149%)   222 
(+365%)   930 (+11%)1032

utf-32be  'A'*1   461 (+216%)   454 (+221%)   292 
(+399%)   1209 (+20%)   1456
utf-32be  '\x80'*1457 (+177%)   454 (+179%)   271 
(+368%)   1125 (+13%)   1268
utf-32be'\x80'+'A'*   462 (+171%)   453 (+176%)   271 
(+362%)   1112 (+12%)   1251
utf-32be  '\u0100'*1  457 (+144%)   453 (+146%)   220 
(+407%)   1048 (+6%)1116
utf-32be'\u0100'+'A'* 462 (+139%)   454 (+143%)   220 
(+402%)   1034 (+7%)1104
utf-32be'\u0100'+'\x80'*  459 (+142%)   453 (+145%)   220 
(+405%)   1047 (+6%)1112
utf-32be  '\u8000'*1  457 (+144%)   453 (+147%)   220 
(+408%)   1046 (+7%)1117
utf-32be'\u8000'+'A'* 462 (+139%)   454 (+143%)   220 
(+402%)   1034 (+7%)1104
utf-32be'\u8000'+'\x80'*  459 (+142%)   453 (+145%)   220 
(+405%)   1045 (+6%)1112
utf-32be'\u8000'+'\u0100'*459 (+142%)   454 (+144%)   220 
(+404%)   1047 (+6%)1109
utf-32be  '\U0001'*1  386 (+155%)   416 (+137%)   212 
(+364%)   940 (+5%) 984
utf-32be'\U0001'+'A'* 461 (+116%)   415 (+140%)   213 
(+367%)   948 (+5%) 994
utf-32be'\U0001'+'\x80'*  458 (+115%)   415 (+137%)   222 
(+343%)   938 (+5%) 983
utf-32be'\U0001'+'\u0100'*458 (+115%)   415 (+137%)   212 
(+364%)   940 (+5%) 983
utf-32be'\U0001'+'\u8000'*458 (+115%)   415 (+137%)   222 
(+343%)   939 (+5%) 983

On 32-bit Linux, Intel Atom N570 @ 1.66GHz:

  Py2.7 Py3.2 Py3.3 
patchA   patchB

utf-32le  'A'*1   165 (+173%)   165 (+173%)   100 
(+350%)   389 (+16%)450
utf-32le  '\x80'*1165 (+159%)   165 (+159%)   76 
(+462%)374 (+14%)427
utf-32le'\x80'+'A'*   165 (+161%)   165 (+161%)   76 
(+466%)374 (+15%)430
utf-32le  '\u0100'*1  165 (+119%)   165 (+119%)   81 
(+346%)333 (+8%) 361
utf-32le'\u0100'+'A'* 165 (+120%)   165 (+120%)   81 
(+348%)334 (+9%) 363
utf-32le'\u0100'+'\x80'*  165 (+119%)   165 (+119%)   81 
(+347%)334 (+8%) 362
utf-32le  '\u8000'*1  165 (+119%)   165 (+119%)   80 
(+352%)333 (+9%) 362
utf-32le'\u8000'+'A'* 165 (+119%)   165 (+119%)   81 
(+347%)334 (+8%) 362
utf-32le'\u8000'+'\x80'*  165 (+119%)   165 (+119%)   81 
(+347%)334 (+8%) 362
utf-32le'\u8000'+'\u0100'*165 (+118%)   165 (+118%)   81 
(+343%)333 (+8%) 359
utf-32le  '\U0001'*1  155 (+130%)   151 (+136%)   80 
(+346%)324 (+10%)357
utf-32le'\U0001'+'A'* 165 (+117%)   165 (+117%)   80 
(+348%)325 (+10%)358
utf-32le'\U0001'+'\x80'*  165 (+118%)   165 (+118%)   80 
(+349%)325 (+10%)359
utf-32le'\U0001'+'\u0100'*165 (+116%)   165 (+116%)   80 
(+346%)324 (+10%)357
utf-32le'\U0001'+'\u8000'*99

[issue14596] struct.unpack memory leak

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Here is a patch that implements method __sizeof__ for Struct. This can
be used to limit the caching. In any case, it is useful to know the real
memory consumption of the object.

I'm not sure of the correctness of the method implementation.

--
Added file: http://bugs.python.org/file25325/struct_sizeof.patch

___
Python tracker 

___diff -r c820aa9c0c00 Modules/_struct.c
--- a/Modules/_struct.c Fri Apr 20 18:04:03 2012 -0400
+++ b/Modules/_struct.c Mon Apr 23 16:57:18 2012 +0300
@@ -1752,6 +1752,19 @@
 return PyLong_FromSsize_t(self->s_size);
 }
 
+static PyObject *
+s_sizeof(PyStructObject *self, void *unused)
+{
+Py_ssize_t res;
+formatcode *code;
+
+res = sizeof(PyStructObject) + sizeof(formatcode);
+for (code = self->s_codes; code->fmtdef != NULL; code++) {
+res += sizeof(formatcode);
+}
+return PyLong_FromSsize_t(res);
+}
+
 /* List of functions */
 
 static struct PyMethodDef s_methods[] = {
@@ -1760,6 +1773,8 @@
 {"unpack",  s_unpack,   METH_O, s_unpack__doc__},
 {"unpack_from", (PyCFunction)s_unpack_from, METH_VARARGS|METH_KEYWORDS,
 s_unpack_from__doc__},
+{"__sizeof__",  (PyCFunction)s_sizeof, METH_NOARGS,
+ "Returns size in memory, in bytes"},
 {NULL,   NULL}  /* sentinel */
 };
 
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14654] More fast utf-8 decoding

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

The utf-8 decoder is already well optimized. I propose a patch, which 
accelerates the utf-8 decoder for some of the frequent cases even more 
(+10-30%). In particular, for 2-bites non-latin1 codes will get about +30%.

This is not the final result of optimization. It may be possible to optimize 
the decoding of the ascii and mostly-ascii text (up to the speed of memcpy), 
decoding of text with occasional errors, reduce code duplication. But I'm not 
sure of the success.

Related issues:
[issue4868] Faster utf-8 decoding
[issue13417] faster utf-8 decoding
[issue14419] Faster ascii decoding
[issue14624] Faster utf-16 decoder
[issue14625] Faster utf-32 decoder

--
components: Interpreter Core
files: decode_utf8.patch
keywords: patch
messages: 159080
nosy: haypo, pitrou, storchaka
priority: normal
severity: normal
status: open
title: More fast utf-8 decoding
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file25326/decode_utf8.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

The vista specific path is included there for completeness, if and when code 
moves to that platform, besides showing what the "emulated CV" is actually 
emulating.

Also, I am aware of the old/new GIL, but our console game uses python 2.7 and 
the old GIL will be living on for many a good year, just like 2.7 will.

But you make a good point.  I had forgotten that the new GIL is actually 
implemented with emulated condition variables (current version contributed by 
myself :). I think a different patch is in order, where ceval_gil.h makes use 
of the platform specific "condition variable" services as declared in 
thread_platform.h.  There is no point in duplicating code.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14654] More fast utf-8 decoding

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Here are the results of benchmarking (numbers in MB/s).

On 32-bit Linux, AMD Athlon 64 X2 4600+ @ 2.4GHz:

  Py2.7 Py3.2 Py3.3 
   patch

utf-8 'A'*1   191 (+790%)   1170 (+45%)   1664 
(+2%)1700
utf-8 '\x80'*1187 (+4%) 219 (-11%)172 
(+13%)194
utf-8   '\x80'+'A'*   191 (+98%)1152 (-67%)   376 (+1%) 
378
utf-8 '\u0100'*1  188 (+15%)221 (-2%) 164 
(+32%)217
utf-8   '\u0100'+'A'* 191 (+103%)   1150 (-66%)   382 (+1%) 
387
utf-8   '\u0100'+'\x80'*  188 (+15%)221 (-2%) 164 
(+32%)217
utf-8 '\u8000'*1  244 (-12%)263 (-18%)191 
(+13%)215
utf-8   '\u8000'+'A'* 191 (+102%)   1174 (-67%)   382 (+1%) 
386
utf-8   '\u8000'+'\x80'*  188 (+15%)216 (+0%) 164 
(+32%)217
utf-8   '\u8000'+'\u0100'*188 (+15%)216 (+0%) 164 
(+32%)217
utf-8 '\U0001'*1  251 (-15%)248 (-14%)199 (+7%) 
213
utf-8   '\U0001'+'A'* 191 (+97%)1173 (-68%)   372 (+1%) 
376
utf-8   '\U0001'+'\x80'*  188 (+21%)221 (+3%) 180 
(+26%)227
utf-8   '\U0001'+'\u0100'*188 (+21%)221 (+3%) 180 
(+26%)227
utf-8   '\U0001'+'\u8000'*244 (-9%) 263 (-16%)201 
(+10%)221

On 32-bit Linux, Intel Atom N570 @ 1.66GHz:

  Py2.7 Py3.2 Py3.3 
   patch

utf-8 'A'*1   117 (+414%)   349 (+72%)597 (+1%) 
601
utf-8 '\x80'*186 (-5%)  89 (-8%)  67 (+22%) 
82
utf-8   '\x80'+'A'*   117 (+6%) 340 (-64%)126 (-2%) 
124
utf-8 '\u0100'*1  86 (-2%)  89 (-6%)  66 (+27%) 
84
utf-8   '\u0100'+'A'* 117 (+5%) 339 (-64%)78 (+58%) 
123
utf-8   '\u0100'+'\x80'*  86 (-2%)  89 (-6%)  66 (+27%) 
84
utf-8 '\u8000'*1  109 (-26%)98 (-17%) 71 (+14%) 
81
utf-8   '\u8000'+'A'* 116 (+7%) 339 (-63%)78 (+59%) 
124
utf-8   '\u8000'+'\x80'*  86 (-3%)  89 (-7%)  66 (+26%) 
83
utf-8   '\u8000'+'\u0100'*86 (-3%)  89 (-7%)  66 (+26%) 
83
utf-8 '\U0001'*1  106 (-14%)105 (-13%)81 (+12%) 
91
utf-8   '\U0001'+'A'* 116 (+12%)338 (-62%)127 (+2%) 
130
utf-8   '\U0001'+'\x80'*  86 (+6%)  88 (+3%)  69 (+32%) 
91
utf-8   '\U0001'+'\u0100'*86 (+6%)  88 (+3%)  69 (+32%) 
91
utf-8   '\U0001'+'\u8000'*109 (-24%)98 (-15%) 74 (+12%) 
83

The results were ambiguous (everywhere plus, but in different ways). I
would like to see the results for 64-bit platforms. For scripts see
issue14624.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3177] Add shutil.open

[STINNER Victor]

Changes by STINNER Victor :


--
nosy:  -haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14648] Attempt to format ascii and non-ascii strings together fails with "... UCS2 ..."

[STINNER Victor]

STINNER Victor  added the comment:

 "{0:s}{1:s}".format("ABC", "\u0410\u0411\u0412")
> python: Objects/unicodeobject.c:1223: _copy_characters: Assertion `ch <= 
> to_maxchar' failed.

Attached patch fixes this issue.

--
keywords: +patch
Added file: http://bugs.python.org/file25327/format_nonascii.patch

___
Python tracker 

___diff -r 6762b943ee59 Lib/test/test_unicode.py
--- a/Lib/test/test_unicode.py  Tue Apr 17 21:42:07 2012 -0400
+++ b/Lib/test/test_unicode.py  Mon Apr 23 16:25:13 2012 +0200
@@ -924,6 +924,14 @@ class UnicodeTest(string_tests.CommonTes
 self.assertRaises(ValueError, format, '', '#')
 self.assertRaises(ValueError, format, '', '#20')
 
+# Non-ASCII
+self.assertEqual("{0:s}{1:s}".format("ABC", "\u0410\u0411\u0412"),
+ 'ABC\u0410\u0411\u0412')
+self.assertEqual("{0:.3s}".format("ABC\u0410\u0411\u0412"),
+ 'ABC')
+self.assertEqual("{0:.0s}".format("ABC\u0410\u0411\u0412"),
+ '')
+
 def test_format_map(self):
 self.assertEqual(''.format_map({}), '')
 self.assertEqual('a'.format_map({}), 'a')
diff -r 6762b943ee59 Objects/unicodeobject.c
--- a/Objects/unicodeobject.c   Tue Apr 17 21:42:07 2012 -0400
+++ b/Objects/unicodeobject.c   Mon Apr 23 16:25:13 2012 +0200
@@ -1957,6 +1957,37 @@ PyUnicode_FromKindAndData(int kind, cons
 }
 }
 
+Py_UCS4
+_PyUnicode_FindMaxChar(PyObject *unicode, Py_ssize_t start, Py_ssize_t end)
+{
+enum PyUnicode_Kind kind;
+void *startptr, *endptr;
+
+assert(PyUnicode_IS_READY(unicode));
+assert(0 <= start);
+assert(end <= PyUnicode_GET_LENGTH(unicode));
+assert(start <= end);
+
+if (start == 0 && end == PyUnicode_GET_LENGTH(unicode))
+return PyUnicode_MAX_CHAR_VALUE(unicode);
+
+if (start == end)
+return 127;
+
+kind = PyUnicode_KIND(unicode);
+startptr = PyUnicode_DATA(unicode);
+endptr = (char*)startptr + end * kind;
+if (start)
+startptr = (char*)startptr + start * kind;
+switch(kind)
+{
+case PyUnicode_1BYTE_KIND: return ucs1lib_find_max_char(startptr, endptr);
+case PyUnicode_2BYTE_KIND: return ucs2lib_find_max_char(startptr, endptr);
+default:
+case PyUnicode_4BYTE_KIND: return ucs4lib_find_max_char(startptr, endptr);
+}
+}
+
 /* Ensure that a string uses the most efficient storage, if it is not the
case: create a new string with of the right kind. Write NULL into *p_unicode
on error. */
diff -r 6762b943ee59 Python/formatter_unicode.c
--- a/Python/formatter_unicode.cTue Apr 17 21:42:07 2012 -0400
+++ b/Python/formatter_unicode.cMon Apr 23 16:25:13 2012 +0200
@@ -713,10 +713,10 @@ format_string_internal(PyObject *value, 
 Py_ssize_t lpad;
 Py_ssize_t rpad;
 Py_ssize_t total;
-Py_ssize_t pos;
+Py_ssize_t i, pos;
 Py_ssize_t len = PyUnicode_GET_LENGTH(value);
 PyObject *result = NULL;
-Py_UCS4 maxchar = 127;
+Py_UCS4 ch, maxchar = 127;
 
 /* sign is not allowed on strings */
 if (format->sign != '\0') {
@@ -752,8 +752,12 @@ format_string_internal(PyObject *value, 
 if (lpad != 0 || rpad != 0)
 maxchar = Py_MAX(maxchar, format->fill_char);
 
+ch = _PyUnicode_FindMaxChar(value, 0, len);
+maxchar = Py_MAX(maxchar, ch);
+
 /* allocate the resulting string */
 result = PyUnicode_New(total, maxchar);
+printf("maxchar = 0x%x\n", maxchar);
 if (result == NULL)
 goto done;
 
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14655] traceback module docs should show how to print/fomat an exception object

[R. David Murray]

New submission from R. David Murray :

Suppose you have an exception object acquired from somewhere.  The exception is 
no longer active on the stack.  Now you want to format the exception like 
format_exception would (to log it, perhaps).  To do this you apparently need to 
call:

  format_exception(type(exc), exc, exc.__traceback__)

This seems redundant, so it would be nice to have a simpler call.  Too bad the 
name format_exception is already taken.  But, leaving that aside, the above is 
not documented in the traceback module.  The last example shows the (type(exc), 
exc) call form for format_exception_only, but that's as close as it gets.

--
messages: 159084
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: traceback module docs should show how to print/fomat an exception object
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14654] More fast utf-8 decoding

[Antoine Pitrou]

Antoine Pitrou  added the comment:

64-bit Linux, Intel Core i5-2500K CPU @ 3.30GHz:

  vanilla 3.3   patched
utf-8 'A'*1   6668 (+7%)7145
utf-8 'A'*+'\x80' 2358 (+3%)2418
utf-8 'A'*+'\u0100'   2306 (+0%)2311
utf-8 'A'*+'\u8000'   2299 (+0%)2309
utf-8 'A'*+'\U0001'   2373 (-4%)2278
utf-8 '\x80'*1366 (+53%)559
utf-8   '\x80'+'A'*   859 (+1%) 868
utf-8 '\x80'*+'\u0100'529 (+5%) 558
utf-8 '\x80'*+'\u8000'529 (+5%) 558
utf-8 '\x80'*+'\U0001'529 (+5%) 558
utf-8 '\u0100'*1  520 (+6%) 549
utf-8   '\u0100'+'A'* 822 (+0%) 823
utf-8   '\u0100'+'\x80'*  519 (+6%) 549
utf-8 '\u0100'*+'\u8000'  520 (+6%) 549
utf-8 '\u0100'*+'\U0001'  520 (+6%) 549
utf-8 '\u8000'*1  470 (+4%) 491
utf-8   '\u8000'+'A'* 822 (+0%) 822
utf-8   '\u8000'+'\x80'*  509 (+8%) 549
utf-8   '\u8000'+'\u0100'*509 (+8%) 549
utf-8 '\u8000'*+'\U0001'  470 (-4%) 451
utf-8 '\U0001'*1  483 (-6%) 453
utf-8   '\U0001'+'A'* 938 (-1%) 926
utf-8   '\U0001'+'\x80'*  561 (+6%) 595
utf-8   '\U0001'+'\u0100'*561 (+6%) 595
utf-8   '\U0001'+'\u8000'*503 (-4%) 482

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14654] More fast utf-8 decoding

[STINNER Victor]

STINNER Victor  added the comment:

> 64-bit Linux, Intel Core i5-2500K CPU @ 3.30GHz: (...)

Hum, the patch doesn't look very interesting if it only optimize one
specific case:

> utf-8     '\x80'*1                    366 (+53%)    559

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14648] Attempt to format ascii and non-ascii strings together fails with "... UCS2 ..."

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 139c3ae84772 by Victor Stinner in branch 'default':
Close #14648: Compute correctly maxchar in str.format() for substrin
http://hg.python.org/cpython/rev/139c3ae84772

--
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14656] Add a macro for unreachable code

[Benjamin Peterson]

New submission from Benjamin Peterson :

It would be nice to have a macro Py_UNREACHABLE to keep compiler warnings away 
in unreachable code. This is can call __builtin_unreachable on gcc and abort 
elsewhere.

--
components: Interpreter Core
keywords: easy
messages: 159088
nosy: benjamin.peterson
priority: normal
severity: normal
stage: needs patch
status: open
title: Add a macro for unreachable code
type: enhancement
versions: Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14572] 2.7.3: sqlite module does not build on centos 5

[Marc Abramowitz]

Marc Abramowitz  added the comment:

This patch worked for me as well. Thanks, Joakim!

$ cat /etc/redhat-release 
CentOS release 5.5 (Final)

--
nosy: +Marc.Abramowitz

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14624] Faster utf-16 decoder

[Antoine Pitrou]

Antoine Pitrou  added the comment:

64 bit Linux, Intel Core i5-2500K @ 3.30GHz:

  vanilla 3.3   patched

utf-16le  'A'*1   1384 (+278%)  5233
utf-16le  'A'*+'\x80' 1303 (+259%)  4684
utf-16le  'A'*+'\u0100'   953 (+195%)   2813
utf-16le  'A'*+'\u8000'   953 (+195%)   2814
utf-16le  'A'*+'\U0001'   979 (+197%)   2903
utf-16le  '\x80'*11243 (+321%)  5230
utf-16le'\x80'+'A'*   1256 (+313%)  5188
utf-16le  '\x80'*+'\u0100'880 (+214%)   2765
utf-16le  '\x80'*+'\u8000'880 (+214%)   2763
utf-16le  '\x80'*+'\U0001'899 (+218%)   2860
utf-16le  '\u0100'*1  1047 (+370%)  4917
utf-16le'\u0100'+'A'* 1046 (+369%)  4906
utf-16le'\u0100'+'\x80'*  1047 (+370%)  4920
utf-16le  '\u0100'*+'\u8000'  1047 (+369%)  4906
utf-16le  '\u0100'*+'\U0001'  791 (+253%)   2793
utf-16le  '\u8000'*1  230 (+410%)   1173
utf-16le'\u8000'+'A'* 1043 (+371%)  4911
utf-16le'\u8000'+'\x80'*  1044 (+345%)  4645
utf-16le'\u8000'+'\u0100'*1041 (+350%)  4681
utf-16le  '\u8000'*+'\U0001'  215 (+357%)   983
utf-16le  '\U0001'*1  362 (+170%)   976
utf-16le'\U0001'+'A'* 985 (+210%)   3052
utf-16le'\U0001'+'\x80'*  985 (+211%)   3066
utf-16le'\U0001'+'\u0100'*983 (+209%)   3042
utf-16le'\U0001'+'\u8000'*245 (+329%)   1052

utf-16be  'A'*1   1268 (+313%)  5240
utf-16be  'A'*+'\x80' 1199 (+297%)  4758
utf-16be  'A'*+'\u0100'   896 (+211%)   2786
utf-16be  'A'*+'\u8000'   897 (+211%)   2788
utf-16be  'A'*+'\U0001'   919 (+214%)   2885
utf-16be  '\x80'*11154 (+341%)  5087
utf-16be'\x80'+'A'*   1155 (+343%)  5112
utf-16be  '\x80'*+'\u0100'829 (+229%)   2728
utf-16be  '\x80'*+'\u8000'828 (+229%)   2726
utf-16be  '\x80'*+'\U0001'852 (+232%)   2832
utf-16be  '\u0100'*1  981 (+332%)   4241
utf-16be'\u0100'+'A'* 981 (+330%)   4220
utf-16be'\u0100'+'\x80'*  977 (+331%)   4213
utf-16be  '\u0100'*+'\u8000'  982 (+331%)   4237
utf-16be  '\u0100'*+'\U0001'  748 (+237%)   2520
utf-16be  '\u8000'*1  230 (+413%)   1180
utf-16be'\u8000'+'A'* 979 (+331%)   4218
utf-16be'\u8000'+'\x80'*  974 (+333%)   4215
utf-16be'\u8000'+'\u0100'*972 (+335%)   4226
utf-16be  '\u8000'*+'\U0001'  215 (+361%)   992
utf-16be  '\U0001'*1  362 (+170%)   978
utf-16be'\U0001'+'A'* 924 (+232%)   3064
utf-16be'\U0001'+'\x80'*  921 (+223%)   2979
utf-16be'\U0001'+'\u0100'*921 (+233%)   3064
utf-16be'\U0001'+'\u8000'*245 (+329%)   1052

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14654] More fast utf-8 decoding

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


--
nosy: +jcea

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com