[ python-Feature Requests-1275677 ] add a get() method to sets

2005-08-30 Thread SourceForge.net
Feature Requests item #1275677, was opened at 2005-08-29 14:49
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Antoine Pitrou (pitrou)
Assigned to: Raymond Hettinger (rhettinger)
Summary: add a get() method to sets

Initial Comment:
Hi,

I would like to propose a new method for the builtin
set objects. Currently we have a pop() method which
pops an element from the set. What I often need,
though, is a method that gets an arbitrary element
without removing it (because adding / removing stuff is
dealt with in
another part of the program).

Right now the simplest way to do that is :
value = iter(my_set).next()

There are two problems with this:
1. it's ugly and not very intuitive
2. it is not atomic; this means if another thread
updates the set, I can get a "RuntimeError: dictionary
changed size during iteration" (btw, the message is
slightly wrong, it should be "set" instead of "dictionary")

Although the first problem is rather minor (but
annoying nevertheless), the second one is a real
showstopper in some cases - yes, I did encounter it for
real.

There is a way to avoid the second problem :
value = list(my_set)[0]
But of course, not only it is still ugly, but it is
also highly inefficient when the set is big. So in the
end I am forced to use an explicit lock around the
aforementioned construct (value = iter(my_set).next())
as well as around any other piece of code that can
update the set from another thread. This is tedious and
error-prone, and probably a bit inefficient.

So for the bottom line: it would be in some cases very
useful to have an atomic get() method in addition to
the pop() method on sets. (it could probably be applied
to frozensets and dicts too)

The implementation would probably not be very
difficult, since it's the same as pop() with the
removal feature removed. ;) But I'm not familiar with
the Python internals.

What do you think ?

Regards

Antoine.


--

>Comment By: Michael Hudson (mwh)
Date: 2005-08-30 08:03

Message:
Logged In: YES 
user_id=6656

Mmm, the "v, = s" approach hadn't occurred to me and it seems ok.  The 
others are all rather horribly indirect... (and, obviously, it's not about 
"need").

--

Comment By: Antoine Pitrou (pitrou)
Date: 2005-08-30 00:09

Message:
Logged In: YES 
user_id=133955

Hi again,

> Antoine, yes a pop()/add() combination is efficient.

Ok, thanks.

>  IMO,
> it also clear in intent, easy to write, flexible enough for
> a variety of applications, the pop() is atomic, 

Small correction: the pop() is atomic, but the pop/add
sequence is not, AFAIU ;)

> Question for Antoine:  Have you ever had this need with
> other containers?

I think I had it for a dict sometime. For lists and tuples,
you can just use my_container[0] of course.
But sets are often used differently than dicts IMHO. Dicts
are mappings: you give a precise key and get the exact value
associated with it. Sets are bags: sometimes you just want
to pick an item, as you would do in a real bag, without
looking inside to choose a specific item.

> Since choose() would not be a
> mutating method, it would also apply to frozensets.  Does it
> have any use there?  Any appearance in a loop would be farce
> since it would always return the same value (the frozenset
> never mutates).

The variable to which you apply the method call could
reference another frozenset on the next loop iteration...
Yes, it doesn't sound very frequent.

> Question for everyone:  Is there any known application for
> choose() that isn't met by pop()/add() irrespective of
> whether it "feels right"?

I don't think so indeed. (it would be the case if the API
guaranteed atomicity in the case of single bultin method
calls like choose())

> For applications other than Michael's, we won't know the
> size of the set in advance.  Are there any examples of using
> choose() that won't have to have ugly EAFP or LBYL code to
> handle the case where the set is empty?

First, sometimes you know the set is non-empty without
knowing its size in advance (for example you are inside a
big block beginning with "if len(my_set)"). Second, error
catching is still needed with other alternatives (you either
have to catch KeyError when doing s.pop(), or StopIteration
when doing iter(s).next()).

> Rather than a method just for sets, is it a more appropriate
> solution to have a generic function that takes any iterable
> and returns its first element:

Well, I thought global builtin functions were less favoured
than 

[ python-Bugs-1010952 ] running test_codecmaps_* takes too much effort

2005-08-30 Thread SourceForge.net
Bugs item #1010952, was opened at 2004-08-18 04:13
Message generated for change (Comment added) made by perky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010952&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Hye-Shik Chang (perky)
Summary: running test_codecmaps_* takes too much effort

Initial Comment:
The only way I've found to actually run the codecmap tests is by 
running it over and over again, downloading the missing files when 
a test complains in between, until the tests no longer complains.

E.g 
$ make test
- test_codecmap_jp complains about a missing file
- download this file
$ make test
- test_codecmap_jp complains about another missing filie
- ...

Another problem: it is completely unclear where I should place the 
downloaded files. I've worked around this by placing the files in 
Lib/test and patching test_multibytecodec_support to look for the 
files in os.path.dirname(__file__):

cvs diff: Diffing .
Index: test_multibytecodec_support.py
=
==
RCS file: /cvsroot/python/python/dist/src/Lib/test/
test_multibytecodec_support.py,v
retrieving revision 1.5
diff -r1.5 test_multibytecodec_support.py
165a166
> self.mapfilename = 
os.path.join(os.path.dirname(__file__), self.mapfilename)

It would be nice if there were a document that described what 
should be done to run these tests, adding the required files to CVS 
would be fine too :-)

--

>Comment By: Hye-Shik Chang (perky)
Date: 2005-08-30 16:06

Message:
Logged In: YES 
user_id=55188

I wrote a patch that draws on lemburg's suggestion.
Please test it: SF #1276356.

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-10-14 05:04

Message:
Logged In: YES 
user_id=38388

Just a suggestion:

Why don't we add a new resource option to the test scripts
and then have the tests download the files from the Internet
as necessary ?!


--

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-10-14 04:59

Message:
Logged In: YES 
user_id=469548

How about adding the files to nondist?

--

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-10-14 00:12

Message:
Logged In: YES 
user_id=29957

Could we at least get a single tarball/zip file of all of
the files? At the moment, it takes a serious amount of
effort to fetch all the files.



--

Comment By: Martin v. Löwis (loewis)
Date: 2004-08-20 16:26

Message:
Logged In: YES 
user_id=21627

Adding the files to the CVS is unacceptable, because they
would then end up in the distribution, and their size is
considered unacceptable for distribution (let alone
copyright issues with these files).

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2004-08-18 04:19

Message:
Logged In: YES 
user_id=580910

test_normalization suffers from a simular problem.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010952&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1276437 ] error converting locale number to decimal

2005-08-30 Thread SourceForge.net
Bugs item #1276437, was opened at 2005-08-30 11:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276437&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: oswaldo (oswaldohm)
Assigned to: Nobody/Anonymous (nobody)
Summary: error converting locale number to decimal

Initial Comment:
Hello,

When I try con convert a locale formated number to
decimal y generate an error:

>>> import locale
>>> import decimal
>>> locale.setlocale(locale.LC_ALL, "sp")
'Spanish_Spain.1252'
>>> n = locale.format("%f", 123456.78, 1)
>>> n
'123.456,78'
>>> d = decimal.Decimal(n)
  File "", line 1, in ?
  File "C:\Python24\Lib\decimal.py", line 571, in __new__
self._sign, self._int, self._exp =
context._raise_error(ConversionSyntax)
  File "C:\Python24\Lib\decimal.py", line 2266, in
_raise_error
raise error, explanation
''' decimal.InvalidOperation :  '''
>>> 

Thanks

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276437&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1251300 ] Decoding with unicode_internal segfaults on UCS-4 builds

2005-08-30 Thread SourceForge.net
Bugs item #1251300, was opened at 2005-08-03 21:49
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251300&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nik Haldimann (nhaldimann)
Assigned to: Walter Dörwald (doerwalter)
Summary: Decoding with unicode_internal segfaults on UCS-4 builds

Initial Comment:
On UCS-4 builds, decoding a byte string with the
unicode_internal codec doesn't correctly work for code
points from 0x8000 upwards and even segfaults. I
have observed the same behaviour on 2.5 from CVS and
2.4.0 on OS X/PowerPC as well as on 2.3.5 on Linux/x86.
Here's an example:

Python 2.5a0 (#1, Aug  3 2005, 21:34:05) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on
darwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> "\x7f\xff\xff\xff".decode("unicode_internal")
u'\U7fff'
>>> "\x80\x00\x00\x00".decode("unicode_internal")
u'\x00'
>>> "\x80\x00\x00\x01".decode("unicode_internal")
u'\x01'
>>> "\x81\x00\x00\x00".decode("unicode_internal")
Segmentation fault

On little endian architectures the byte strings must be
reversed for the same effect.

I'm not sure if I understand what's going on, but I
guess there are 2 solution strategies:

1. Make unicode_internal work for any code point up to
0x.

2. Make unicode_internal raise a UnicodeDecodeError for
anything above 0x10 (== sys.maxunicode for UCS-4
builds).

It seems like there are no unicode code points above
0x10, so the latter solution feels more correct to
me, even though it might break backwards compatibility
a tiny bit. The unicodeescape codec already does a
similar thing:

>>> u"\U0011"
UnicodeDecodeError: 'unicodeescape' codec can't decode
bytes in position 0-9: illegal Unicode character


--

>Comment By: Walter Dörwald (doerwalter)
Date: 2005-08-30 12:47

Message:
Logged In: YES 
user_id=89016

I've checked in a version that detects truncated data as:

Include/unicodeobject.h 2.49
Lib/test/test_codeccallbacks.py 1.18
Lib/test/test_codecs.py 1.26
Misc/NEWS 1.1358
Modules/_codecsmodule.c 2.22
Objects/unicodeobject.c 2.231

and

Include/unicodeobject.h 2.48.2.1
Lib/test/test_codeccallbacks.py 1.16.4.2
Lib/test/test_codecs.py 1.15.2.8
Misc/NEWS 1.1193.2.92
Modules/_codecsmodule.c 2.20.2.2
Objects/unicodeobject.c 2.230.2.1

Thanks for the patch!

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-08-19 17:45

Message:
Logged In: YES 
user_id=38388

Assigning to Walter, the error handler expert :-)

--

Comment By: Walter Dörwald (doerwalter)
Date: 2005-08-19 17:39

Message:
Logged In: YES 
user_id=89016

The data the handler sees is nonsensical by definition. ;)
To get an idea how to handle an incorrect length, take a
look at Objects/unicodeobject.c::PyUnicode_DecodeUTF16Stateful()

--

Comment By: Nik Haldimann (nhaldimann)
Date: 2005-08-19 16:17

Message:
Logged In: YES 
user_id=1317086

I agree about the ifdefs. I'm not sure about how to handle
input strings of incorrect length. I guess raising an
UnicodeDecodeError is in order. But I think it doesn't make
sense to let it pass through the error handler, since the
data the handler would see is potentially nonsensical (e.g.,
the code point value). Can you comment on this? Is it ok to
raise a UnicodeDecodeError and skip the error handler here?

--

Comment By: Walter Dörwald (doerwalter)
Date: 2005-08-18 22:17

Message:
Logged In: YES 
user_id=89016

The patch has a problem with input strings of a length that
is not a multiple of 4, e.g.
"\x00".decode("unicode-internal") returns u"" instead of
raising an error. Also in a UCS-2 build most of the tests
are irrelevant (as it's not possible to create codepoints
above 0x10 even when using surrogates), so probably they
should be ifdef'd out.

--

Comment By: Nik Haldimann (nhaldimann)
Date: 2005-08-05 23:08

Message:
Logged In: YES 
user_id=1317086

Here's the patch with error handler support + test. Again:
Please review carefully.

--

Comment By: Nik Haldimann (nhaldimann)
Date: 2005-08-05 18:35

Message:
Logged In: YES 
user_id=1317086

Ah, that PEP clears some things up for me. I will look into
it, but I hope you realize this requires tinkering with
unicodeobject.c since the error handler cod

[ python-Bugs-1276437 ] error converting locale number to decimal

2005-08-30 Thread SourceForge.net
Bugs item #1276437, was opened at 2005-08-30 11:16
Message generated for change (Settings changed) made by oswaldohm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276437&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: oswaldo (oswaldohm)
>Assigned to: Facundo Batista (facundobatista)
Summary: error converting locale number to decimal

Initial Comment:
Hello,

When I try con convert a locale formated number to
decimal y generate an error:

>>> import locale
>>> import decimal
>>> locale.setlocale(locale.LC_ALL, "sp")
'Spanish_Spain.1252'
>>> n = locale.format("%f", 123456.78, 1)
>>> n
'123.456,78'
>>> d = decimal.Decimal(n)
  File "", line 1, in ?
  File "C:\Python24\Lib\decimal.py", line 571, in __new__
self._sign, self._int, self._exp =
context._raise_error(ConversionSyntax)
  File "C:\Python24\Lib\decimal.py", line 2266, in
_raise_error
raise error, explanation
''' decimal.InvalidOperation :  '''
>>> 

Thanks

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276437&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1276509 ] 2.4.1 make fails on Solaris 10

2005-08-30 Thread SourceForge.net
Bugs item #1276509, was opened at 2005-08-30 12:48
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276509&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: csmuc (chrschaffer)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4.1 make fails on Solaris 10

Initial Comment:
Hi all,

my efforts building Python 2.4.1 on Solaris 10(x386)
failed.

The error mesage reads:
(...)Objects/complexobject.c: In function `complex_pow':
Objects/complexobject.c:479: error: invalid operands to
binary ==
Objects/complexobject.c:479: error: wrong type argument
to unary minus
Objects/complexobject.c:479: error: invalid operands to
binary ==
Objects/complexobject.c:479: error: wrong type argument
to unary minus
*** Error code 1
make: Fatal error: Command failed for target
`Objects/complexobject.o'

I found bug 970334 dealing with that topic, but I
didn't find a solution provided.

I tried with various compilers and libraries, e.g.
/opt/sfw/bin/gcc --version
gcc (GCC) 3.4.2
Copyright (C) 2004 Free Software Foundation, Inc.
/opt/csw/gcc3/bin/gcc --version
gcc (GCC) 3.4.4
Copyright (C) 2004 Free Software Foundation, Inc.
/usr/local/bin/gcc --version
gcc (GCC) 3.3.2

The same result with any of them.

I didn't get the solution provided in
http://mail.python.org/pipermail/python-list/2005-August/293795.html
to work for me, unfortunately.

I'd be glad, if you could have a look into this issue.

Thanks in advance,
Chris


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276509&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1276437 ] error converting locale number to decimal

2005-08-30 Thread SourceForge.net
Bugs item #1276437, was opened at 2005-08-30 18:16
Message generated for change (Comment added) made by quiver
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276437&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: oswaldo (oswaldohm)
Assigned to: Facundo Batista (facundobatista)
Summary: error converting locale number to decimal

Initial Comment:
Hello,

When I try con convert a locale formated number to
decimal y generate an error:

>>> import locale
>>> import decimal
>>> locale.setlocale(locale.LC_ALL, "sp")
'Spanish_Spain.1252'
>>> n = locale.format("%f", 123456.78, 1)
>>> n
'123.456,78'
>>> d = decimal.Decimal(n)
  File "", line 1, in ?
  File "C:\Python24\Lib\decimal.py", line 571, in __new__
self._sign, self._int, self._exp =
context._raise_error(ConversionSyntax)
  File "C:\Python24\Lib\decimal.py", line 2266, in
_raise_error
raise error, explanation
''' decimal.InvalidOperation :  '''
>>> 

Thanks

--

Comment By: George Yoshida (quiver)
Date: 2005-08-30 19:48

Message:
Logged In: YES 
user_id=671362

I guess this is because '123.456,78' does not conform to 
the decimal numeric string syntax :
  decimal-part   ::=  digits '.' [digits] | ['.'] digits

see : http://docs.python.org/lib/node177.html

It does not seem to be a bug to me.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276437&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Feature Requests-1275677 ] add a get() method to sets

2005-08-30 Thread SourceForge.net
Feature Requests item #1275677, was opened at 2005-08-29 08:49
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Antoine Pitrou (pitrou)
Assigned to: Raymond Hettinger (rhettinger)
Summary: add a get() method to sets

Initial Comment:
Hi,

I would like to propose a new method for the builtin
set objects. Currently we have a pop() method which
pops an element from the set. What I often need,
though, is a method that gets an arbitrary element
without removing it (because adding / removing stuff is
dealt with in
another part of the program).

Right now the simplest way to do that is :
value = iter(my_set).next()

There are two problems with this:
1. it's ugly and not very intuitive
2. it is not atomic; this means if another thread
updates the set, I can get a "RuntimeError: dictionary
changed size during iteration" (btw, the message is
slightly wrong, it should be "set" instead of "dictionary")

Although the first problem is rather minor (but
annoying nevertheless), the second one is a real
showstopper in some cases - yes, I did encounter it for
real.

There is a way to avoid the second problem :
value = list(my_set)[0]
But of course, not only it is still ugly, but it is
also highly inefficient when the set is big. So in the
end I am forced to use an explicit lock around the
aforementioned construct (value = iter(my_set).next())
as well as around any other piece of code that can
update the set from another thread. This is tedious and
error-prone, and probably a bit inefficient.

So for the bottom line: it would be in some cases very
useful to have an atomic get() method in addition to
the pop() method on sets. (it could probably be applied
to frozensets and dicts too)

The implementation would probably not be very
difficult, since it's the same as pop() with the
removal feature removed. ;) But I'm not familiar with
the Python internals.

What do you think ?

Regards

Antoine.


--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-30 06:47

Message:
Logged In: YES 
user_id=80475

> > Question for everyone:  Is there any known application for
> > choose() that isn't met by pop()/add() irrespective of
> > whether it "feels right"?
[Antoine]
> I don't think so indeed. 

[mwh]
> Mmm, the "v, = s" approach hadn't occurred to me and it 
> seems ok. 

Those two answers suggest this RFE is unnecessary.  If you
guys agree, please close.  If not, I'll ponder it further. 
Right now, I'm disinclined to introduce a method that I
think is awkward to use.

--

Comment By: Michael Hudson (mwh)
Date: 2005-08-30 02:03

Message:
Logged In: YES 
user_id=6656

Mmm, the "v, = s" approach hadn't occurred to me and it seems ok.  The 
others are all rather horribly indirect... (and, obviously, it's not about 
"need").

--

Comment By: Antoine Pitrou (pitrou)
Date: 2005-08-29 18:09

Message:
Logged In: YES 
user_id=133955

Hi again,

> Antoine, yes a pop()/add() combination is efficient.

Ok, thanks.

>  IMO,
> it also clear in intent, easy to write, flexible enough for
> a variety of applications, the pop() is atomic, 

Small correction: the pop() is atomic, but the pop/add
sequence is not, AFAIU ;)

> Question for Antoine:  Have you ever had this need with
> other containers?

I think I had it for a dict sometime. For lists and tuples,
you can just use my_container[0] of course.
But sets are often used differently than dicts IMHO. Dicts
are mappings: you give a precise key and get the exact value
associated with it. Sets are bags: sometimes you just want
to pick an item, as you would do in a real bag, without
looking inside to choose a specific item.

> Since choose() would not be a
> mutating method, it would also apply to frozensets.  Does it
> have any use there?  Any appearance in a loop would be farce
> since it would always return the same value (the frozenset
> never mutates).

The variable to which you apply the method call could
reference another frozenset on the next loop iteration...
Yes, it doesn't sound very frequent.

> Question for everyone:  Is there any known application for
> choose() that isn't met by pop()/add() irrespective of
> whether it "feels right"?

I don't think so indeed. (it would be the case if the API
guaranteed atomicity in the case of single bultin method
calls like choose())

> For applications other than Michael's, we won't know the
> size of the set in advance.  Are there any examples o

[ python-Bugs-1276587 ] dict('') doesn't raise a value error

2005-08-30 Thread SourceForge.net
Bugs item #1276587, was opened at 2005-08-30 12:52
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276587&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Foord (mjfoord)
Assigned to: Nobody/Anonymous (nobody)
Summary: dict('') doesn't raise a value error

Initial Comment:
The dict function will theoretically accept any sequence 
or bounded iterable that yields (key, value) tuples.

A side effect is that dict('') is valid - producing an emtpy 
dictionary.

dict(x) where x is *any* string other than '' fails with a 
ValueError. I suggest that dict('') ought to produce a 
ValueError to as a string is *never* a valid input to the 
dict function.

The current situation allows obscure errors to pass 
unnoticed.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276587&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1258485 ] http auth documentation/implementation conflict

2005-08-30 Thread SourceForge.net
Bugs item #1258485, was opened at 2005-08-13 16:49
Message generated for change (Comment added) made by mjfoord
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1258485&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: http auth documentation/implementation conflict

Initial Comment:
 [forwarded from http://bugs.debian.org/304925]

Bug reporter writes:

I was trying to implement a basic HTTP client using
HTTP basic
authorization. The current preferred method of doing
this is by using
urllib2 HTTPPasswordMgr. 

A simple test snippet to try this:

pwmgr=urllib2.HTTPPasswordMgrWithDefaultRealm()
pwmgr.add_password(None, url, username, password)
handler=urllib2.HTTPBasicAuthHandler(pwmgr)
opener=urllib2.build_opener(handler)
urllib2.install_opener(opener)
u=urllib2.urlopen(url)

This did not work. Modifying the second line to:

pwmgr.add_password(None, urlparse.urlparse(url)[1],
username, password)

fixed things, which shows a problem in the
documentation: instead of
a URI or sequence of URIs the add_password method takes
a hostname. 

The documented behaviour would be better since it
allows for multiple
passwords per host, although in reality those will use
different realms.
So I suggest not changing the code in order to not
break existing
application but fixing the documentation instead.



--

Comment By: Mike Foord (mjfoord)
Date: 2005-08-30 12:58

Message:
Logged In: YES 
user_id=1123892

I think it likely that the OP was using a URL that *included* 
the protocol - (i.e. "http://www.somedomain.com/path";) 
instead of just "www.somedomain.com/path".

It is a problem that also bit me - and could *definitely* do with 
a mention in the docs.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1258485&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1276587 ] dict('') doesn't raise a value error

2005-08-30 Thread SourceForge.net
Bugs item #1276587, was opened at 2005-08-30 08:52
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276587&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Foord (mjfoord)
Assigned to: Nobody/Anonymous (nobody)
Summary: dict('') doesn't raise a value error

Initial Comment:
The dict function will theoretically accept any sequence 
or bounded iterable that yields (key, value) tuples.

A side effect is that dict('') is valid - producing an emtpy 
dictionary.

dict(x) where x is *any* string other than '' fails with a 
ValueError. I suggest that dict('') ought to produce a 
ValueError to as a string is *never* a valid input to the 
dict function.

The current situation allows obscure errors to pass 
unnoticed.

--

>Comment By: Tim Peters (tim_one)
Date: 2005-08-30 10:39

Message:
Logged In: YES 
user_id=31435

It's not theoretical:  it's a fact that dict() accepts any iterable 
producing iterables each producing 2 objects (the latter don't 
have to be tuples; a (key, value) tuple is just one kind of 
iterable producing 2 objects; e.g., dict(["ab"]) == {'a': 'b'}).

An empty str meets the input requirements, so there's no 
way to stop this without special-case type-sniffing.  That's 
very unattractive, in part because it's impossible to guess 
which kinds of empty iterables would necessarily lead to an 
exception when passed to dict() had they not been empty.  
For example, passing an empty array.array (of any flavor) to 
dict() also constructs an empty dict.  The universe of iterable 
objects is vast.

Keeping it uniform and easy to explain (an empty iterable 
produces an empty dict) seems better to me than adding a 
maze of special cases that's bound to change over time 
("except for an empty str" ... "oh, or an empty 
unicode" ... "oh, or an empty array.array" ... "oh, or an empty 
file" ... "oh, oops, guess not, cuz a file with two lines works 
fine" ... etc).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276587&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1276768 ] dirutils.mkpath (verbose option does not work)

2005-08-30 Thread SourceForge.net
Bugs item #1276768, was opened at 2005-08-30 15:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276768&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: gorilla_killa (gorilla_killa)
Assigned to: Nobody/Anonymous (nobody)
Summary: dirutils.mkpath (verbose option does not work)

Initial Comment:
The Verbose option does not work.

Looked at the python script for dir_utils.py and the
verbose parameter is not used in the code.

Please fix this simple bug.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276768&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1276437 ] error converting locale number to decimal

2005-08-30 Thread SourceForge.net
Bugs item #1276437, was opened at 2005-08-30 11:16
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276437&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: oswaldo (oswaldohm)
Assigned to: Facundo Batista (facundobatista)
Summary: error converting locale number to decimal

Initial Comment:
Hello,

When I try con convert a locale formated number to
decimal y generate an error:

>>> import locale
>>> import decimal
>>> locale.setlocale(locale.LC_ALL, "sp")
'Spanish_Spain.1252'
>>> n = locale.format("%f", 123456.78, 1)
>>> n
'123.456,78'
>>> d = decimal.Decimal(n)
  File "", line 1, in ?
  File "C:\Python24\Lib\decimal.py", line 571, in __new__
self._sign, self._int, self._exp =
context._raise_error(ConversionSyntax)
  File "C:\Python24\Lib\decimal.py", line 2266, in
_raise_error
raise error, explanation
''' decimal.InvalidOperation :  '''
>>> 

Thanks

--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-08-30 21:23

Message:
Logged In: YES 
user_id=1188172

Correct. Decimal cannot guess which locale your number
string might be in, so please format the float using regular
string formatting and not locale.format.

--

Comment By: George Yoshida (quiver)
Date: 2005-08-30 12:48

Message:
Logged In: YES 
user_id=671362

I guess this is because '123.456,78' does not conform to 
the decimal numeric string syntax :
  decimal-part   ::=  digits '.' [digits] | ['.'] digits

see : http://docs.python.org/lib/node177.html

It does not seem to be a bug to me.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276437&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Feature Requests-1275677 ] add a get() method to sets

2005-08-30 Thread SourceForge.net
Feature Requests item #1275677, was opened at 2005-08-29 08:49
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Antoine Pitrou (pitrou)
Assigned to: Raymond Hettinger (rhettinger)
Summary: add a get() method to sets

Initial Comment:
Hi,

I would like to propose a new method for the builtin
set objects. Currently we have a pop() method which
pops an element from the set. What I often need,
though, is a method that gets an arbitrary element
without removing it (because adding / removing stuff is
dealt with in
another part of the program).

Right now the simplest way to do that is :
value = iter(my_set).next()

There are two problems with this:
1. it's ugly and not very intuitive
2. it is not atomic; this means if another thread
updates the set, I can get a "RuntimeError: dictionary
changed size during iteration" (btw, the message is
slightly wrong, it should be "set" instead of "dictionary")

Although the first problem is rather minor (but
annoying nevertheless), the second one is a real
showstopper in some cases - yes, I did encounter it for
real.

There is a way to avoid the second problem :
value = list(my_set)[0]
But of course, not only it is still ugly, but it is
also highly inefficient when the set is big. So in the
end I am forced to use an explicit lock around the
aforementioned construct (value = iter(my_set).next())
as well as around any other piece of code that can
update the set from another thread. This is tedious and
error-prone, and probably a bit inefficient.

So for the bottom line: it would be in some cases very
useful to have an atomic get() method in addition to
the pop() method on sets. (it could probably be applied
to frozensets and dicts too)

The implementation would probably not be very
difficult, since it's the same as pop() with the
removal feature removed. ;) But I'm not familiar with
the Python internals.

What do you think ?

Regards

Antoine.


--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-30 15:06

Message:
Logged In: YES 
user_id=80475

For the record, here are some research results.

Java's set objects do not have a choose() method:
http://java.sun.com/j2se/1.4.2/docs/api/java/util/Set.html

In contrast, SETL does provide a function for extracting
arbitrary elements.  The empty set case is handled by
returning Om which is a singleton object guaranteed not to
be an element of any set.  The Om value is especially useful
in SETL because it can be passed upward through other
functions (much in the same way that NANs can trickle
through a calculation without killing it).  Python has no
equivalent of Om.
  http://www.cs.nyu.edu/~bacon/setl-doc.html#arb

Core Perl only has arrays and hashes.

Mathematica provides set operations on lists (union,
intersection, complement).  Rather than having a set
specific function for extraction, list functions are used. 
The one providing choose-like functionality is First().  It
is equivalent to indexing:  a[0]
http://documents.wolfram.com/mathematica/functions/First



--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-30 06:47

Message:
Logged In: YES 
user_id=80475

> > Question for everyone:  Is there any known application for
> > choose() that isn't met by pop()/add() irrespective of
> > whether it "feels right"?
[Antoine]
> I don't think so indeed. 

[mwh]
> Mmm, the "v, = s" approach hadn't occurred to me and it 
> seems ok. 

Those two answers suggest this RFE is unnecessary.  If you
guys agree, please close.  If not, I'll ponder it further. 
Right now, I'm disinclined to introduce a method that I
think is awkward to use.

--

Comment By: Michael Hudson (mwh)
Date: 2005-08-30 02:03

Message:
Logged In: YES 
user_id=6656

Mmm, the "v, = s" approach hadn't occurred to me and it seems ok.  The 
others are all rather horribly indirect... (and, obviously, it's not about 
"need").

--

Comment By: Antoine Pitrou (pitrou)
Date: 2005-08-29 18:09

Message:
Logged In: YES 
user_id=133955

Hi again,

> Antoine, yes a pop()/add() combination is efficient.

Ok, thanks.

>  IMO,
> it also clear in intent, easy to write, flexible enough for
> a variety of applications, the pop() is atomic, 

Small correction: the pop() is atomic, but the pop/add
sequence is not, AFAIU ;)

> Question for Antoine:  Have you ever had this need with
> other containers?

I think

[ python-Bugs-1277016 ] Sentence fragment in urlparse documentation

2005-08-30 Thread SourceForge.net
Bugs item #1277016, was opened at 2005-08-30 19:57
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277016&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Chad Whitacre (whit537)
Assigned to: Nobody/Anonymous (nobody)
Summary: Sentence fragment in urlparse documentation

Initial Comment:
The urlparse documentation contains this sentence fragment:

"This should generally be used instead of urlparse() if
the more recent URL syntax allowing parameters to be
applied to each segment of the path portion of the URL
(see RFC 2396)."[1]

>From the context, I infer that the sentence should read
something like:

"This should generally be used instead of urlparse() if
you do not wish to support the more recent URL syntax
allowing parameters to be applied to each segment of
the path portion of the URL (see RFC 2396)."


-

[1]
http://www.python.org/dev/doc/devel/lib/module-urlparse.html

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277016&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1277098 ] imaplib Imap.select() uses comparison to 'None' for boolean

2005-08-30 Thread SourceForge.net
Bugs item #1277098, was opened at 2005-08-31 15:52
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277098&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Thorne (jerub)
Assigned to: Nobody/Anonymous (nobody)
Summary: imaplib Imap.select() uses comparison to 'None' for boolean

Initial Comment:
The imap class's method for selecting a mailbox in read
only mode is subtly broken. Calling i.select('INBOX',
readonly=0) will cause the imap library to open the
mailbox in EXAMINE mode, not SELECT.

 def select(self, mailbox='INBOX', readonly=None):
 if readonly is not None:
 name = 'EXAMINE'
 else:
 name = 'SELECT'

So passing what seems to be a boolean option into the
function causes unexpected circumstances in client code.

Recommend that the comparison be changed to 'if readonly:'.

I have verified this code exists in python2.3 and in
python cvs head.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277098&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1277098 ] imaplib Imap.select() uses comparison to 'None' for boolean

2005-08-30 Thread SourceForge.net
Bugs item #1277098, was opened at 2005-08-31 15:52
Message generated for change (Comment added) made by jerub
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277098&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Thorne (jerub)
>Assigned to: Piers Lauder (pierslauder)
Summary: imaplib Imap.select() uses comparison to 'None' for boolean

Initial Comment:
The imap class's method for selecting a mailbox in read
only mode is subtly broken. Calling i.select('INBOX',
readonly=0) will cause the imap library to open the
mailbox in EXAMINE mode, not SELECT.

 def select(self, mailbox='INBOX', readonly=None):
 if readonly is not None:
 name = 'EXAMINE'
 else:
 name = 'SELECT'

So passing what seems to be a boolean option into the
function causes unexpected circumstances in client code.

Recommend that the comparison be changed to 'if readonly:'.

I have verified this code exists in python2.3 and in
python cvs head.

--

>Comment By: Stephen Thorne (jerub)
Date: 2005-08-31 15:54

Message:
Logged In: YES 
user_id=100823

assigned to pierslauder as per abaxter's request.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277098&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com