Ned Deily added the comment:
Sorry, I'm unable to reproduce your results and they look rather suspicious.
Keep in mind that the Python build uses its copy of Distutils to build and
install the interpreter's shared extension modules, like _ctypes.so. My guess
is that your make install is
Ned Deily added the comment:
Let's consolidate these.
--
nosy: +ned.deily
resolution: - duplicate
stage: - committed/rejected
status: open - closed
superseder: - during Python installation, setup.py should not use
.pydistutils.cfg
___
Python
Ned Deily added the comment:
rdm notes in duplicate Issue6138:
There is a bug here, of some sort. Either the .pydistutils.cfg file's
install clause should override the default --prefix somehow, or the
error message should indicate where the setting for 'home' and
'--prefix' came from to enable
New submission from Firat Ozgul:
lower() method of strings gives different output for 'Latin Capital Letter I
with Dot Above' on Python 3.2 and Python 3.3.
On Python 3.2 (Windows XP):
\u0130.lower()
'i' #this is correct
On Python 3.3 (Windows XP):
\u0130.lower()
'i\u0307' #this is wrong
Michael Kuhn added the comment:
Thanks a lot Ned: you're right, the unexpected path was indeed set in
~/.pydistutils.cfg. So I agree with what has been written in the other issues,
that the installation should detect the clash between the command line
configuration and the configuration file
Changes by Dirkjan Ochtman dirk...@ochtman.nl:
--
nosy: +djc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17239
___
___
Python-bugs-list mailing
R. David Murray added the comment:
I thought this would just be a difference in the unicode database, but that
appears not to be the case. Ezio, this is related to the infamous Turkic
dotless lower case i problem (see, eg,
Firat Ozgul added the comment:
In Python, things like lowercasing-uppercasing and sorting were always
problematic with regard to Turkish language. For instance, whatever the locale
is, you cannot lowercase the word 'KADIN' (woman) in Turkish correctly::
KADIN.lower()
'kadin'
...
New submission from Jason R Briggs:
The sys.stdin.readline function takes a limit parameter, which limits the
number of characters read. If you try using that parameter in IDLE, you get the
following error:
Traceback (most recent call last):
File pyshell#1, line 1, in module
New submission from albertjan:
This is almost identical to: http://bugs.python.org/issue854511
However, tis602, which is mentioned in the orginal bug report, is not an alias
to cp874. Therefore, I propose the following:
import encodings
aliases = encodings.aliases.aliases
more_aliases =
Jason R Briggs added the comment:
Note, that change I quoted would be in idlelib/PyShell.py
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17253
___
R. David Murray added the comment:
Right, and the unicode consortium says that that weird thing 3.3 is doing is
the canonical lowercasing, and this is the case exactly because in 3.3
\u0130.lower().upper() == \u0130. Which I why I asked Ezio if we ever came
up with a way to do lower/upper in
Antoine Pitrou added the comment:
Good, except that you have to add a gc.collect() call for the non-refcounted
implementations.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15004
___
Marc-Andre Lemburg added the comment:
On 20.02.2013 12:48, albertjan wrote:
New submission from albertjan:
This is almost identical to: http://bugs.python.org/issue854511
However, tis602, which is mentioned in the orginal bug report, is not an
alias to cp874. Therefore, I propose the
Firat Ozgul added the comment:
r.david.murray: '(...) because in 3.3 \u0130.lower().upper() == \u0130'
Do you mean in Python 3.3 \u0130.lower() returns \u0130?
If you are saying so, this is not the case, because in Python 3.3::
'\u0130'.lower()
'i\u0307'
--
Antoine Pitrou added the comment:
Yes, I think 3.3 is correct here. I think it was Benjamin who fixed/improved
the behaviour of casing methods. Compare 3.3:
ß.upper()
'SS'
with 3.2:
ß.upper()
'ß'
Also, 3.2 loses information:
KİTAP.lower().upper()
'KITAP'
ascii(KİTAP.lower().upper())
New submission from wim glenn:
The docs http://docs.python.org/2/library/functions.html#all provide some
equivalent code for all builtin (and similarly for any):
def all(iterable):
for element in iterable:
if not element:
return False
return True
The behaviour is
Firat Ozgul added the comment:
Don't you think that there is a problem here?
KİTAP.lower().upper()
'KİTAP'
ascii(KİTAP.lower().upper())
'KI\\u0307TAP'
İ is not i\u0307. That's a different letter. i\u0307is 'i with combining
dot above'. However, İ is \u0130 (Latin Capital Letter I with Dot
Firat Ozgul added the comment:
ascii(KİTAP.lower().upper()) should return K\u0130TAP.
Yes, Python 3.2 loses information, but Python 3.3 inserts faulty information,
which, I think, is much worse than losing information.
--
___
Python tracker
R. David Murray added the comment:
Ah, you are right, I did not decode it to see what the actual characters were.
That does contradict what I said, but I'm way out of my depth on unicode at
this point, so we'll have to wait for someone more expert to weigh in.
--
Serhiy Storchaka added the comment:
Already fixed in issue9290.
--
nosy: +serhiy.storchaka
resolution: - out of date
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17253
Piotr Dobrogost added the comment:
I could try to write a patch with some help if there was any chance it might be
accepted. Where do I start?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17164
Changes by Firat Ozgul ozgulfi...@gmail.com:
--
resolution: invalid -
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17252
___
Firat Ozgul added the comment:
Excerpt from http://www.unicode.org/Public/UNIDATA/SpecialCasing.txt
# Turkish and Azeri
# I and i-dotless; I-dot and i are case pairs in Turkish and Azeri
# The following rules handle those cases.
0130; 0069; 0130; 0130; tr; # LATIN CAPITAL LETTER I WITH DOT
Richard Oudkerk added the comment:
Good, except that you have to add a gc.collect() call for the
non-refcounted implementations.
Better to use test.support.gc_collect().
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
Benjamin Peterson added the comment:
Notice the lines you pulled have tr and az at the end of them meaning they
only apply for Turkish and Azeri. Since the lower() method has no idea whether
the user intends to be in a Turkish or Azeri locale or not, we just have to use
the generic lowering
Firat Ozgul added the comment:
Even if you set Turkish locale, the output is still generic.
Furthermore, does canonical equivalence really dictate that 'Latin Capital
Letter I with Dot Above' should be mapped to 'I With Combining Dot Above' in
lowercase?
Note: 'Uppercase Dotted i' only
Ramchandra Apte added the comment:
Shouldn't this be deferred blocker?
--
nosy: +Ramchandra Apte
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16245
___
Ramchandra Apte added the comment:
I suppose this should be closed.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
___
Ramchandra Apte added the comment:
I think so.
--
nosy: +Ramchandra Apte
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue886488
___
___
Ramchandra Apte added the comment:
Is this still valid?
--
nosy: +Ramchandra Apte
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1398781
___
___
Firat Ozgul added the comment:
Whatever the behavior of Python is in 'generic' terms, I believe, we should be
able to do locale-dependent uppercasing-lowercasing, which we cannot do at the
moment.
--
___
Python tracker rep...@bugs.python.org
Christian Heimes added the comment:
The bug hasn't been closed deliberately. We need to announce the security fix
and possibly acquire a CVE, too.
--
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
albertjan added the comment:
Hi,
I found this report that includes your name:
http://mail.python.org/pipermail/python-bugs-list/2004-August/024564.html
Other relevant websites:
http://en.wikipedia.org/wiki/ISO/IEC_8859-11 # is wikipedia 'proof'?
R. David Murray added the comment:
Yes, earlier in that file is the generic translation:
# Preserve canonical equivalence for I with dot. Turkic is handled below.
0130; 0069 0307; 0130; 0130; # LATIN CAPITAL LETTER I WITH DOT ABOVE
You see that Python is following the standard, here.
Agreed
New submission from Ramchandra Apte:
in http://docs.python.org/2/extending/embedding.html#linking-requirements
the code example isn't highlighted
--
assignee: docs@python
components: Documentation
messages: 182515
nosy: Ramchandra Apte, docs@python
priority: normal
severity: normal
Changes by Ramchandra Apte maniandra...@gmail.com:
--
versions: +Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17256
___
___
Ramchandra Apte added the comment:
Also in the section above:
http://docs.python.org/2/extending/embedding.html#extending-embedded-python ,
the two code examples should be highlighted.
--
___
Python tracker rep...@bugs.python.org
Changes by Ramchandra Apte maniandra...@gmail.com:
--
title: code example should be highlighted - code example in C API docsshould
be highlighted
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17256
Firat Ozgul added the comment:
Apparently, what Python did wrong in the past was somewhat good for Turkish
Python developers! This means Turkish developers now have one more problem to
solve. Bad.
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
İ is not i\u0307. That's a different letter. i\u0307is 'i with
combining dot above'. However, İ is \u0130 (Latin Capital Letter
I with Dot Above).
Did you actually read my message? You can reconcile the two using
unicodedata.normalize().
--
Benjamin Peterson added the comment:
The locale module does not affect Unicode operations. That's C locale; I'm
talking about concept of Unicode locale, which Python doesn't currently know
anything about.
I agree it would be useful to customize the locale of various unicode
operations.
Marc-Andre Lemburg added the comment:
On 20.02.2013 15:58, Benjamin Peterson wrote:
Benjamin Peterson added the comment:
The locale module does not affect Unicode operations. That's C locale; I'm
talking about concept of Unicode locale, which Python doesn't currently know
anything
Christian Heimes added the comment:
In the meantime you can use PyICU https://pypi.python.org/pypi/PyICU for locale
aware transformations:
from icu import UnicodeString, Locale
tr = Locale(TR)
s = UnicodeString(KADIN)
print(unicode(s.toLower(tr)))
kadın
unicode(s.toLower(tr))
Marc-Andre Lemburg added the comment:
On 20.02.2013 15:40, albertjan wrote:
albertjan added the comment:
Hi,
I found this report that includes your name:
http://mail.python.org/pipermail/python-bugs-list/2004-August/024564.html
Other relevant websites:
Jason R. Coombs added the comment:
I've started work on restoring the directory detection in my bitbucket repo
(https://bitbucket.org/jaraco/cpython-issue13772). I have added a regression
test to capture the basic failure (where the link is not created in the current
working directory) as
Zachary Ware added the comment:
I believe we're also waiting on input from Barry about whether to apply the
patch to 2.6.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
___
Barry A. Warsaw added the comment:
Does the 2.x patch apply cleanly to 2.6? If so, then I think it should be
applied (though I'd like to review it first). 2.6 is still under security
maintenance until October 2013. I'm thinking we'll probably do one last
security release around that time.
Zachary Ware added the comment:
Does the 2.x patch apply cleanly to 2.6?
It should, if I remember correctly, though I haven't checked since
uploading it. I believe there were actually very few or no changes to the
file the patch is for between 2.6 and 2.7.
--
Changes by Barry A. Warsaw ba...@python.org:
--
versions: +Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
___
___
Python-bugs-list
albertjan added the comment:
Sent: Wednesday, February 20, 2013 4:25 PM
Subject: [issue17254] add thai encoding aliases to encodings.aliases
Thanks.
Something is wrong with your request, though:
* we already have an iso8859_11 code, so aliasing it to some
other name is not possible
Barry A. Warsaw added the comment:
Release blocking for 2.6.9 (oh how I wish we could release block for specific
Python versions).
--
nosy: +georg.brandl, larry
priority: normal - release blocker
___
Python tracker rep...@bugs.python.org
R. David Murray added the comment:
Looks like there's no reason for this issue to still be open. If I'm wrong one
of the principles can reopen it ;)
--
nosy: +r.david.murray
stage: - committed/rejected
status: open - closed
___
Python tracker
Serhiy Storchaka added the comment:
mirabilos, if you are motivated enough, do the following. Compile two Python
executables - one with deleted assert, and second with deleted a block between
#if SIZEOF_LONG = SIZEOF_VOID_P and #endif. Run following microbenchmarks
for both executables:
Changes by Stefan Krah stefan-use...@bytereef.org:
--
resolution: - works for me
stage: - committed/rejected
status: pending - closed
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17241
Antoine Pitrou added the comment:
Barry A. Warsaw added the comment:
Does the 2.x patch apply cleanly to 2.6?
Perhaps it's your job as a release manager to check that ;-P
--
___
Python tracker rep...@bugs.python.org
Roundup Robot added the comment:
New changeset 9b37e53838eb by Serhiy Storchaka in branch '2.7':
Issue #15301: Enhance os.*chown() testing. Based on patch by Larry Hastings.
http://hg.python.org/cpython/rev/9b37e53838eb
New changeset a0baf5347cd1 by Serhiy Storchaka in branch '3.2':
Issue
Roundup Robot added the comment:
New changeset 0383a54347ea by Serhiy Storchaka in branch '2.7':
Issue #17248: Fix os.*chown() testing when user has group root.
http://hg.python.org/cpython/rev/0383a54347ea
New changeset a49bbaadce67 by Serhiy Storchaka in branch '3.2':
Issue #17248: Fix
New submission from Hendrik Lemelson:
When using the Python 2.7.3 re module, it shows a strange behavior upon the use
of quantifiers together with groups:
re.search('(a*)', 'ct').groups()
('',)
re.search('(a+)', 'ct').groups()
('',)
re.search('(a{0,5})', 'ct').groups()
('',)
Serhiy Storchaka added the comment:
Fixed.
--
assignee: - serhiy.storchaka
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17248
Serhiy Storchaka added the comment:
I have no access to Windows and can't design Windows tests.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6975
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
versions: +Python 3.2, Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17257
___
R. David Murray added the comment:
Unfortunately, no it isn't.
root isn't my primary group, it just one of the groups I belong to.
--
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17248
Tim Peters added the comment:
This is how it's supposed to work: Python's re matches at the leftmost
position possible, and _then_ matches the longest possible substring at that
position. When a regexp _can_ match 0 characters, it will match starting at
index 0. So, e.g.,
Arfrever Frehtes Taifersar Arahesis added the comment:
Use os.path.sep and os.path.sep.encode() instead of hardcoding / and b/.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6975
___
Ezio Melotti added the comment:
In order to fix test discovery on Windows the attached patch should be enough.
There are two somewhat unrelated issues though:
1) moving replace_stdout to test.support (and possibly turn it into a context
manager/decorator);
2) use unittest verbosity to control
Ezio Melotti added the comment:
I left a few comments on rietveld.
In the rst docs the markup used for arguments is *arg*, and this is sometimes
reflected in docstrings too. We might want to do this here too, instead of
using 'arg' (using 'attr' for attributes it's fine though).
maybe
Ezio Melotti added the comment:
Before I take any time to update the patch, does anyone object
to the location or intent of the changes?
Adding a new page to the devguide seems OK to me. It makes the devguide
bigger, but it can easily be ignored by developers/contributors if they are not
Chris Jerdonek added the comment:
Looks like it's because highlightlang:: c is at the top.
--
nosy: +chris.jerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17256
___
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +ezio.melotti
stage: - needs patch
type: - enhancement
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17256
___
mirabilos added the comment:
Serhiy Storchaka dixit:
mirabilos, if you are motivated enough, do the following. Compile two
Python executables - one with deleted assert, and second with deleted
a block between #if SIZEOF_LONG = SIZEOF_VOID_P and #endif. Run
following microbenchmarks for both
Zachary Ware added the comment:
Here's a new version of the patch, with the fixes that Ned pointed out.
I also tried to address concerns about lost information; menu divisions have
been added to Doc/library/idle.rst, along with the blurb about running without
a subprocess being deprecated.
Changes by Zachary Ware zachary.w...@gmail.com:
Removed file: http://bugs.python.org/file28725/issue16893.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16893
___
New submission from Dave Malcolm:
Within multiprocessing.connection, deliver_challenge() and
answer_challenge() use hmac for a challenge/response.
hmac implicitly defaults to using MD5.
MD5 should no longer be used for security purposes. See e.g.
http://www.kb.cert.org/vuls/id/836068
This
R. David Murray added the comment:
Looks like a straightforward translation to me. There's no obvious reason not
to move it to being a real test, which means it would sure be nice if we knew
why it was left in test_main.
--
nosy: +r.david.murray
Serhiy Storchaka added the comment:
Use os.path.sep and os.path.sep.encode() instead of hardcoding / and
b/.
Some separators will be '\\' (if they are derived from OS functions, i.e.
getcwd), and some will be '/' (if they are generated by posixpath). I do not
have the ability to research
Christian Heimes added the comment:
The statement MD5 should no longer be used for security purposes is not
entirely correct. MD5 should no longer be used as cryptographic hash function
for signatures. However HMAC-MD5 is a different story.
From https://tools.ietf.org/html/rfc6151
The
Serhiy Storchaka added the comment:
Which tree should I build? A release (if so, which)? Or
some CVS branch?
It doesn't matter.
Do note we clock at roughly 1000 pystones for the fastest
machines… yes 1000 not 1.
It doesn't matter. Only relative values have a meaning. What is faster
Serhiy Storchaka added the comment:
And of course run the tests on non-debug builds.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17237
___
Richard Oudkerk added the comment:
Banning md5 as a matter of policy may be perfectly sensible.
However, I think the way multiprocessing uses hmac authentication is *not*
affected by the collision attacks the advisory talks about. These depend on
the attacker being able to determine for
New submission from Francis Nimick:
Locale.format() doesn't work correctly with floating point numbers.
locale.format('%.0f', 5.5) - 6
locale.format('%.0f', 6.5) - 6
locale.format('%.0f', 7.5) - 8
locale.format('%.0f', 8.5) - 8
It seems that if the number before the decimal point is even, it
Serhiy Storchaka added the comment:
http://docs.python.org/library/functions.html#round
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17259
___
Francis Nimick added the comment:
I did end up using round - does that mean the locale.format() behavior is
correct? It's not specified anywhere in the doc that I can find.
--
___
Python tracker rep...@bugs.python.org
Serhiy Storchaka added the comment:
What about this patch?
--
keywords: +patch
Added file: http://bugs.python.org/file29135/test_posix_chown_root_group.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17248
R. David Murray added the comment:
That works.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17248
___
___
Python-bugs-list mailing list
Roundup Robot added the comment:
New changeset 470350fd2831 by Benjamin Peterson in branch '3.3':
fix building without pymalloc (closes #17228)
http://hg.python.org/cpython/rev/470350fd2831
New changeset 67fa0643751d by Benjamin Peterson in branch '2.7':
fix building without pymalloc (closes
R. David Murray added the comment:
Perhaps Serhiy meant to direct your attention to the note in the round docs.
Floating point is tricky.
In Python3 the round is actually half to even. I'm not sure what the
rounding algorithm is for %f, but I have a suspicion it might be half to even.
I
mirabilos added the comment:
Serhiy Storchaka dixit:
Which tree should I build? A release (if so, which)? Or
some CVS branch?
It doesn't matter.
Erm, still, which one do I build? Not 3.2 because it obviously
works, at least as packaged in Debian.
bye,
//mirabilos
--
Yay for having to
Changes by Barry A. Warsaw ba...@python.org:
--
nosy: +doko
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17258
___
___
Python-bugs-list mailing
Changes by Barry A. Warsaw ba...@python.org:
--
nosy: +barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17258
___
___
Python-bugs-list mailing
Changes by Barry A. Warsaw ba...@python.org:
--
nosy: +barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17186
___
___
Python-bugs-list mailing
Changes by Barry A. Warsaw ba...@python.org:
--
nosy: +barry
versions: +Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16037
___
___
Changes by Barry A. Warsaw ba...@python.org:
--
nosy: +barry
versions: +Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16043
___
___
New submission from Johannes:
Running the code attached causes a segmentation fault.
This only occurs when run from within a virtual environment, and when the class
is an old style class.
I've tested on OSX with both 2.7.3 installed via Homebrew, and the default
2.7.2 Python installation.
Changes by Johannes joh...@gmail.com:
--
title: Seg fault when calling unicode() on old style class in virtualenv - Seg
fault when calling unicode() on old style object in virtualenv
___
Python tracker rep...@bugs.python.org
Eric V. Smith added the comment:
Mark is the ultimate authority here, but my recollection is (and a quick scan
of the code shows) that half to even rounding is used in all of our float to
string conversions. So that includes %f and float.__format__, among others.
--
Changes by Antoine Pitrou pit...@free.fr:
--
versions: -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python
3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17258
___
Antoine Pitrou added the comment:
Can you please post a gdb traceback?
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17260
___
Barry A. Warsaw added the comment:
I'm working on applying the 2.x patch to 2.6, but one thing interesting of
note: sudo, at least on Debian and derivatives going back at least to Squeeze,
generally reset the environment by default (i.e. env_reset). So you'd have to
either have disabled
Antoine Pitrou added the comment:
I'm working on applying the 2.x patch to 2.6, but one thing
interesting of note: sudo, at least on Debian and derivatives going
back at least to Squeeze, generally reset the environment by default
(i.e. env_reset). So you'd have to either have disabled
1 - 100 of 117 matches
Mail list logo
