Hello,
in Python (contrary to Perl, for instance) there is one way to do common
tasks. Could somebody explain me what is the official python way of
printing unicode strings?
I tried to do this such way:
s = uStanisław Lem
print u.encode('utf-8')
This works, but is very cumbersome.
Then I tried
1. Comparison sorts have n*ln(n) complexity - does not do
2. Counting sort has the complexity O(d), where d is domain (in our
case n^2) - does not do.
3. Radix sorts have the complexity O(n*k), where k is number of bits
in integer. (32?) There are 2 variants:
a. most significant digit (MSD),
b.
Let me just point out that unsuspecting people (like me) might rely on
the whole expression to be evaluated and rely on exceptions being
raised if needed.
This happens when people assume something ;)
Use a different construct if you want to catch error's, I don't
understand how you could not
On Sat, Dec 13, 2008 at 11:50 PM, Tim Chase
python.l...@tim.thechases.com wrote:
Any special reasons?
Because it is there (at least on my Debian box)?
But not on windows :(
import time
time.strftime(%e)
''
t...@rubbish:~$ python
Python 2.5.2 (r252:60911, May 28 2008, 08:35:32)
En Sun, 14 Dec 2008 02:40:10 -0200, Benjamin Kaplan
benjamin.kap...@case.edu escribió:
On Sat, Dec 13, 2008 at 10:49 PM, Daniel Fetchinson
fetchin...@googlemail.com wrote:
Is it a feature that
1 or 1/0
returns 1 and doesn't raise a ZeroDivisionError? If so, what's the
rationale?
I have a class with a method meant to verify internal program logic (not
data supplied by the caller). Because it is time-consuming but optional,
I treat it as a complex assertion statement, and optimize it away if
__debug__ is false:
class Parrot:
def __init__(self, *args):
print
New submission from dirlt zhang_...@baidu.com:
I found the problem when i install a small tool which I wrote on the
each machine in the company.the problem is simplified as follows:
there are three files
1./home/share/temp/a a regular file
2./home/share/a.lnk which is symbolic link to the
Mark Summerfield m...@qtrac.eu added the comment:
Although I stand by my criticism of IDLE not offering the option of
switching off cursor blink, I've now discovered that the problem was
with Fedora 10 no longer executing xrdb .Xdefaults; once I added that
line to my .bash_profile the cursor
Mark Dickinson dicki...@gmail.com added the comment:
About the name:
Java's Bignum has a 'significantBits' method, which apparently returns
the position of the MSB (i.e., numbits - 1).
GMP has mpz_sizeinbase; mpz_sizeinbase(n, 2) is almost the same as
numbits, except that mpz_sizeinbase(0,
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Perhaps n.bit_length() with an underscore. The name sounds good to my
ear and sensibilities.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3439
Mark Dickinson dicki...@gmail.com added the comment:
Perhaps n.bit_length() with an underscore.
I thought I recalled Guido having a preference for float.fromhex over
float.from_hex when that got implemented. But either spelling seems good
to me.
___
Mark Dickinson dicki...@gmail.com added the comment:
I thought I recalled Guido having a preference for float.fromhex over
Can't find anything to back this up. It looks like I'm just making this
up.
___
Python tracker rep...@bugs.python.org
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
It was probably true. The issue is how well the words self-separate
visually and whether an underscore would create a detrimental mental
pause. So fromkeys() and fromhex() read fine and would feel awkward
with an underscore.
Mark Dickinson dicki...@gmail.com added the comment:
Did you look at the O(lg n) algorithm yet? Any thoughts?
So there are two places this could be applied: the int_numbits method
and _PyLong_NumBits. I'd be quite surprised if this offered any
noticeable speedup in either case. Might be
Retro vinet...@gmail.com added the comment:
What is recommended in PEP 8, you are engouraged to follow that; not you
as a Python coder but you as a member of the Python community where PEP
8 is the coding style specification. Python's built-in modules have such
a lovely coding style because they
Mark Dickinson dicki...@gmail.com added the comment:
Three files:
(1) bit_length7.patch just does the numbits-bit_length renaming;
otherwise it's the same as numbits-6b.patch.
(2) bit_length7_opt.patch uses the fast bitcount method that Raymond
pointed out.
(3) bit_length_pybench.patch
Changes by Mark Dickinson dicki...@gmail.com:
Added file: http://bugs.python.org/file12337/bit_length7_opt.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3439
___
Changes by Mark Dickinson dicki...@gmail.com:
Added file: http://bugs.python.org/file12338/bit_length_pybench.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3439
___
Martin v. Löwis mar...@v.loewis.de added the comment:
Backported r55839 and r61350, as r67726
--
nosy: +loewis
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4469
Antoine Pitrou pit...@free.fr added the comment:
Well, I don't think bit_length() warrants a specific test which will
slow down the whole pybench suite. pybench tracks interpreter speed for
common and generally useful operations, while I think bit_length() is
only a niche method.
--
Martin v. Löwis mar...@v.loewis.de added the comment:
Thanks for the patch. Committed for 2.5 as r67731; integration into the
other branches still needs to happen.
--
assignee: loewis - georg.brandl
priority: release blocker - normal
versions: -Python 2.5, Python 2.5.3
Martin v. Löwis mar...@v.loewis.de added the comment:
Thanks for the patch. Committed as r67732.
--
nosy: +loewis
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4368
Martin v. Löwis mar...@v.loewis.de added the comment:
As the ARM buildbot is still down, we have no way of analysing or fixing
this problem, so I'm closing this as won't fix.
--
resolution: - wont fix
status: open - closed
___
Python tracker
Martin v. Löwis mar...@v.loewis.de added the comment:
Thanks for the patch. Committed (along with a test case) as r67733, in
the 2.5 branch.
Porting to the other branches still needs to happen. Armin, if you want
to make these changes, please go ahead.
--
priority: release blocker -
Changes by Martin v. Löwis mar...@v.loewis.de:
--
priority: normal - deferred blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4228
___
___
Martin v. Löwis mar...@v.loewis.de added the comment:
Committed for 2.5 as r67735. It still needs to be applied to the other
branches.
--
priority: release blocker - deferred blocker
___
Python tracker rep...@bugs.python.org
Martin v. Löwis mar...@v.loewis.de added the comment:
As it is apparently not clear what change exactly needs to be applied to
2.5, I'm declaring that this fix will not be backported.
I would appreciate if somebody could summarize what still needs to be
done, or (if nothing needs to be done),
Mark Dickinson dicki...@gmail.com added the comment:
Well, I don't think bit_length() warrants a specific test which will
slow down the whole pybench suite.
Me neither. It's a temporary patch to pybench, to establish whether it's
worth applying optimizations to bit_length. I didn't intend
Martin v. Löwis mar...@v.loewis.de added the comment:
Committed fork-thread-patch-2 as r67736 into 2.5 branch.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1683
___
Martin v. Löwis mar...@v.loewis.de added the comment:
I can't reproduce the problem. It works fine for me.
--
nosy: +loewis
priority: release blocker - normal
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2996
Mark Dickinson dicki...@gmail.com added the comment:
Slightly improved optimized version.
Added file: http://bugs.python.org/file12339/bit_length7_opt.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3439
Changes by Mark Dickinson dicki...@gmail.com:
Removed file: http://bugs.python.org/file12337/bit_length7_opt.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3439
___
Mark Dickinson dicki...@gmail.com added the comment:
Added another test to pybench; it makes sense to consider cases where the
input n is uniformly distributed in [0, 2**31) as well as cases where the
output n.bit_length() is uniformly distributed in [0, 32).
Added file:
Changes by Mark Dickinson dicki...@gmail.com:
Removed file: http://bugs.python.org/file12338/bit_length_pybench.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3439
___
Martin v. Löwis mar...@v.loewis.de added the comment:
I have backported r59654 as r67737. As indicated, the other patches are
not suitable for backporting.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
Antoine Pitrou pit...@free.fr added the comment:
Here is a new patch without any dispatch shortcut in ceval.c, just
optimizations in unicodeobject.c and longobject.c. Net result on pybench:
Test minimum run-timeaverage run-time
Martin v. Löwis mar...@v.loewis.de added the comment:
Thanks for the patch.
Committed tkColorChooser.diff as r67738 in the 2.5 branch. Applying this
to the other branches still needs to be done.
--
assignee: - loewis
nosy: +loewis
priority: release blocker - deferred blocker
Martin v. Löwis mar...@v.loewis.de added the comment:
Committed os_times5.patch into 2.5 branch as r67739
Applying this to the other branches still needs to be done.
--
assignee: gregory.p.smith - loewis
priority: release blocker - deferred blocker
resolution: - accepted
Changes by Martin v. Löwis mar...@v.loewis.de:
Removed file: http://bugs.python.org/file9514/os_times2.PATCH
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1040026
___
Changes by Martin v. Löwis mar...@v.loewis.de:
Removed file: http://bugs.python.org/file9518/os_times3.PATCH
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1040026
___
Changes by Martin v. Löwis mar...@v.loewis.de:
Removed file: http://bugs.python.org/file9541/posixmodule.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1040026
___
Changes by Martin v. Löwis mar...@v.loewis.de:
Removed file: http://bugs.python.org/file9542/test_posix5.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1040026
___
Mark Dickinson dicki...@gmail.com added the comment:
I think I've found the happy medium:
bit_length7_opt2.patch achieves nearly the same performance gains as
bit_length7_opt.patch (around 7% for uniformly-distributed inputs, 3.5%
for uniformly-distributed outputs), but is much more
Martin v. Löwis mar...@v.loewis.de added the comment:
Thanks for the patch. Committed into the 2.5 branch as r67740. This
still needs to be applied to the other branches.
--
priority: release blocker - deferred blocker
___
Python tracker
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
If there's not a hurry, would like to review this a bit more when I get
back early next week.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3106
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
If there's not a hurry, would like to review this a bit more when I get
back early next week.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3439
Guido van Rossum gu...@python.org added the comment:
Retro, you are blowing this way out of proportion. Style guidelines are
not absolute rules that must be followed at all cost, and there are
always exceptions. You need to have a lot of experience before you can
claim with certainty that a
Guido van Rossum gu...@python.org added the comment:
Don't open a new issue to point out that you just opened a new issue.
About removing getopt.error: if it's in 3.0, it needs to stay or be
properly deprecated. 3.1 has to be backwards compatible with 3.0 for sure.
--
nosy:
Changes by Mark Dickinson dicki...@gmail.com:
Removed file: http://bugs.python.org/file12332/numbits-6b.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3439
___
Antoine Pitrou pit...@free.fr added the comment:
If there's not a hurry, would like to review this a bit more when I get
back early next week.
No pb!
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3106
Fredrik Johansson fredrik.johans...@gmail.com added the comment:
FYI, Brent Zimmermann call this function nbits(n) in Modern Computer
Arithmetic: http://www.loria.fr/~zimmerma/mca/pub226.html
I don't really care much about the name though.
In the documentation, should same value as
Antoine Pitrou pit...@free.fr added the comment:
A couple of suggestions:
- if IncrementalNewlineDecoder gets an encoding argument, it can also
instantiate the decoder itself; that way the API is a bit simpler
- to encode '\r' without the BOM, you can e.g. use an incremental
encoder and encode
Mark Dickinson dicki...@gmail.com added the comment:
In the documentation, should same value as ``x.bit_length`` not be
same value as ``x.bit_length()``?
Yes, of course. Thanks!
Added file: http://bugs.python.org/file12343/bit_length7_opt2.patch
___
Changes by Mark Dickinson dicki...@gmail.com:
Removed file: http://bugs.python.org/file12342/bit_length7_opt2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3439
___
Changes by Mark Dickinson dicki...@gmail.com:
Removed file: http://bugs.python.org/file12339/bit_length7_opt.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3439
___
Changes by Antoine Pitrou pit...@free.fr:
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4574
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou pit...@free.fr added the comment:
Here is a simpler patch with a different approach and a lot of tests.
The advantage is that it doesn't break the API.
Added file: http://bugs.python.org/file12344/utf16_newlines.patch
___
Python tracker
Antoine Pitrou pit...@free.fr added the comment:
This new variant also removes the dangerous hack in getstate / setstate.
Added file: http://bugs.python.org/file12345/utf16_newlines2.patch
___
Python tracker rep...@bugs.python.org
Gregory P. Smith g...@krypto.org added the comment:
should the unit test in test_posix5.patch have been removed? (regardless,
its still on the bug tracker via the history links)
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1040026
Gregory P. Smith g...@krypto.org added the comment:
utf16_newlines2.patch looks good to me.
This is a data corruption issue. If it is deferred for 3.0.1 it must be
fixed in 3.0.2.
+1 on putting this in 3.0.1.
--
assignee: - pitrou
nosy: +gregory.p.smith
priority: - release blocker
Antoine Pitrou pit...@free.fr added the comment:
Attaching a cleanup of the proposed patch. The funny thing is that for
me, both the unpatched and patched versions are as fast as the unzip binary.
Added file: http://bugs.python.org/file12346/zipperf.patch
Antoine Pitrou pit...@free.fr added the comment:
Christian, by benchmarks I meant a measurement of text reading with and
without the patch.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4561
___
Antoine Pitrou pit...@free.fr added the comment:
Here is a patch for the array module.
--
keywords: +needs review, patch
nosy: +pitrou
priority: - critical
stage: - patch review
Added file: http://bugs.python.org/file12347/arraybuf.patch
___
Python
Antoine Pitrou pit...@free.fr added the comment:
I don't know Windows APIs but the pythonrun.c bug is genuine.
--
nosy: +pitrou
priority: - high
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4653
Changes by Antoine Pitrou pit...@free.fr:
--
priority: - normal
stage: - patch review
versions: +Python 3.1 -Python 3.0
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4016
___
Johnny Lee typo...@gmail.com added the comment:
Here are the URLs to the MSDN documentation for CreateFileMapping and
FormatMessage[A|W]:
http://msdn.microsoft.com/en-us/library/aa366537.aspx
http://msdn.microsoft.com/en-us/library/ms679351.aspx
For CreateFileMapping(), from the Return Value
Changes by Martin v. Löwis mar...@v.loewis.de:
Added file: http://bugs.python.org/file9542/test_posix5.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1040026
___
Martin v. Löwis mar...@v.loewis.de added the comment:
should the unit test in test_posix5.patch have been removed?
I see. I wish that people would a) always provide complete patches in
a single file, and b) delete files themselves that have been superceded
by others. In any case, I have
Johnny Lee typo...@gmail.com added the comment:
For the dynload_win.c typo, it's technically a possible buffer
overflow, but you'd need to find an error that had an error message
that's longer than 259 chars.
In pythonrun.c, the if statements for fout and ferr and almost
identical. Probably
Antoine Pitrou pit...@free.fr added the comment:
Fixed in r67746 and r67747. Thanks for the patch!
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4163
Antoine Pitrou pit...@free.fr added the comment:
Just tested the patch, here are some benchmarks:
./python -m timeit -s a=1;b=77 a//b
- 2.6: 0.253 usec per loop
- 3.1: 0.61 usec per loop
- 3.1 + patch: 0.331 usec per loop
./python -m timeit -s a=1;b=77 a*b
- 2.6:
STINNER Victor victor.stin...@haypocalc.com added the comment:
I wrote a small benchmark tool dedicated to integer operations (+ -
* / etc.): bench_int.py attached to issue4294. See also Message75715
and Message75719 for my benchmark results. Short sum up: 2^30 base
helps a lot on 64 bits CPU
New submission from Jake jah.mailingl...@gmail.com:
When installing python 2.6, I used:
./configure --prefix=/home/name/usr
Installation was fine and everything was installed to:
~/usr/lib/python2.6
But the .so files were installed to:
~/usr/lib/python
As ~/usr/lib/python was (no
Nick Coghlan ncogh...@gmail.com added the comment:
After looking into this, I think Alexander is correct. There is no
standard mapping between __file__ and __name__ and linecache is mistaken
in assuming such a mapping exists for all importers (and is the same as
the standard filesystem to name
Changes by Jake jah.mailingl...@gmail.com:
--
title: setup.py should not use .pydistutils.cfg - during Python installation,
setup.py should not use .pydistutils.cfg
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4655
Benjamin Peterson musiccomposit...@gmail.com added the comment:
Fixed in r67748.
--
nosy: +benjamin.peterson
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4523
Nick Coghlan ncogh...@gmail.com added the comment:
The spec get_filename is pretty simple:
Return whatever __file__ would be set to if load_module() was called for
this module.
(runpy's problem is that it never actually loads the module in question,
so it never gets the chance to interrogate
Does the same thing happen with 2.6?
Jeremy
On Thu, Dec 11, 2008 at 8:53 AM, Jean-Paul Calderone
rep...@bugs.python.org wrote:
Jean-Paul Calderone exar...@divmod.com added the comment:
The f65 is the chunk length for the first chunk returned when
requesting that URL. A proxy could easily
New submission from Matthew Cowles mdcow...@users.sourceforge.net:
[From a question sent to the python-help list.]
In the Python 3 tutorial at:
http://docs.python.org/3.0/tutorial/datastructures.html#dictionaries
it says:
The keys() method of a dictionary object returns a list of all the
101 - 179 of 179 matches
Mail list logo