Issue 1050 claims that the 3.1.2 installer has the virus Palevo.DZ.
Can somebody with a virus scanner please confirm or contest that
claim?
Thanks,
Martin
http://bugs.python.org/issue10500
___
Python-Dev mailing list
Python-Dev@python.org
On 28/11/2010 03:20, Terry Reedy wrote:
On 11/27/2010 6:26 PM, Raymond Hettinger wrote:
Can I suggest that an enum-maker be offered as a third-party module
Possibly with competing versions for trial and testing ;-)
rather than prematurely adding it into the standard library.
I had same
On 28/11/2010 02:38, Nick Coghlan wrote:
On Sun, Nov 28, 2010 at 9:26 AM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Nov 27, 2010, at 12:56 PM, Glenn Linderman wrote:
On 11/27/2010 2:51 AM, Nick Coghlan wrote:
Not quite. I'm suggesting a factory function that works for any
On 28/11/2010 16:28, Michael Foord wrote:
[snip...]
I don't think there are *many* competing features, in fact as far as
feature requests on python-dev go I think this is a relatively
straightforward one with a lot of *agreement* on the basic functionality.
We have had various discussions
On 28/11/2010 17:05, Michael Foord wrote:
[snip...]
It is sensible if flag values are only powers of 2; we could enforce
that or not... (Another one for the optional feature list.)
Another 'optional' feature I omitted was Phillip J. Eby's suggestion /
requirement that named values be
Michael Foord wrote:
Another 'optional' feature I omitted was Phillip J. Eby's suggestion /
requirement that named values be pickleable. Email is clunky for
handling this, is there enough support (there is still some objection
that is sure) to revive the PEP or create a new one?
I think it
On 28/11/2010 18:05, Steven D'Aprano wrote:
Michael Foord wrote:
Another 'optional' feature I omitted was Phillip J. Eby's suggestion
/ requirement that named values be pickleable. Email is clunky for
handling this, is there enough support (there is still some objection
that is sure) to
Two recently reported issues brought into light the fact that Python
language definition is closely tied to character properties maintained
by the Unicode Consortium. [1,2] For example, when Python switches to
Unicode 6.0.0 (planned for the upcoming 3.2 release), we will gain two
additional
On Sun, 28 Nov 2010 15:24:37 -0500
Alexander Belopolsky alexander.belopol...@gmail.com wrote:
While we have little choice but to follow UCD in defining
str.isidentifier(), I think Python can promise users more stability in
what it treats as space or as a digit in its builtins.
Well, if unicode
On Sun, Nov 28, 2010 at 3:43 PM, Antoine Pitrou solip...@pitrou.net wrote:
..
For example,
I don't think that supporting
float('١٢٣٤.٥٦')
1234.56
is more important than to assure users that once their program
accepted some text as a number, they can assume that the text is
ASCII.
Why
On Sun, 28 Nov 2010 15:58:33 -0500
Alexander Belopolsky alexander.belopol...@gmail.com wrote:
On Sun, Nov 28, 2010 at 3:43 PM, Antoine Pitrou solip...@pitrou.net wrote:
..
For example,
I don't think that supporting
float('١٢٣٤.٥٦')
1234.56
is more important than to assure users
On Sun, Nov 28, 2010 at 7:04 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 28 Nov 2010 15:58:33 -0500
Alexander Belopolsky alexander.belopol...@gmail.com wrote:
On Sun, Nov 28, 2010 at 3:43 PM, Antoine Pitrou solip...@pitrou.net wrote:
..
For example,
I don't think that supporting
On Sun, Nov 28, 2010 at 4:12 PM, Joao S. O. Bueno jsbu...@python.org.br wrote:
..
Let novice C programmers in English speaking countries deal with the
fact that 1 character is not 1 byte anymore. We are past this point.
If you are, please contribute your expertise here:
Rob Cliffe wrote:
But couldn't they be presented to the Python programmer as a single
type, with the implementation details hidden under the hood?
Not in CPython, because tuple items are kept in the same block
of memory as the object header. Because CPython can't move
objects, this means that
float('١٢٣٤.٥٦')
1234.56
I think it's a bug that this works. The definition of the float builtin says
Convert a string or a number to floating point. If the argument is a
string, it must contain a possibly signed decimal or floating point
number, possibly embedded in whitespace. The argument
On Sun, Nov 28, 2010 at 5:17 PM, Martin v. Löwis mar...@v.loewis.de wrote:
float('١٢٣٤.٥٦')
1234.56
I think it's a bug that this works. The definition of the float builtin says
Convert a string or a number to floating point. If the argument is a
string, it must contain a possibly signed
Martin v. Löwis wrote:
float('١٢٣٤.٥٦')
1234.56
I think it's a bug that this works. The definition of the float builtin says
Convert a string or a number to floating point. If the argument is a
string, it must contain a possibly signed decimal or floating point
number, possibly
Alexander Belopolsky wrote:
Two recently reported issues brought into light the fact that Python
language definition is closely tied to character properties maintained
by the Unicode Consortium. [1,2] For example, when Python switches to
Unicode 6.0.0 (planned for the upcoming 3.2 release),
On Sun, Nov 28, 2010 at 5:42 PM, M.-A. Lemburg m...@egenix.com wrote:
..
I don't see why the language spec should limit the wealth of number
formats supported by float().
The Language Spec (whatever it is) should not, but hopefully the
Library Reference should. If you follow
Am 28.11.2010 23:31, schrieb Alexander Belopolsky:
On Sun, Nov 28, 2010 at 5:17 PM, Martin v. Löwis mar...@v.loewis.de wrote:
float('١٢٣٤.٥٦')
1234.56
I think it's a bug that this works. The definition of the float builtin says
Convert a string or a number to floating point. If the argument
On 11/28/2010 3:58 PM, Alexander Belopolsky wrote:
On Sun, Nov 28, 2010 at 3:43 PM, Antoine Pitrousolip...@pitrou.net wrote:
..
For example,
I don't think that supporting
float('١٢٣٤.٥٦')
1234.56
Even if this is somehow an accident or something that someone snuck in,
I think it a good
On Sun, Nov 28, 2010 at 5:56 PM, Martin v. Löwis mar...@v.loewis.de wrote:
..
This definition fails long before we get beyond 127-th code point:
float('infinity')
inf
What do infer from that? That the definition is wrong, or the code is wrong?
The development version of the reference manual
Now, one may wonder what precisely a possibly signed floating point
number is, but most likely, this refers to
floatnumber ::= pointfloat | exponentfloat
pointfloat::= [intpart] fraction | intpart .
exponentfloat ::= (intpart | pointfloat) exponent
intpart ::= digit+
On 11/28/2010 5:51 PM, Alexander Belopolsky wrote:
The Language Spec (whatever it is) should not, but hopefully the
Library Reference should. If you follow
http://docs.python.org/dev/py3k/library/functions.html#float link and
the references therein, you'll end up with
digit ::=
+1 on all point below.
On Sun, Nov 28, 2010 at 6:03 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Now, one may wonder what precisely a possibly signed floating point
number is, but most likely, this refers to
floatnumber ::= pointfloat | exponentfloat
pointfloat ::= [intpart] fraction
Am 29.11.2010 00:01, schrieb Alexander Belopolsky:
On Sun, Nov 28, 2010 at 5:56 PM, Martin v. Löwis mar...@v.loewis.de wrote:
..
This definition fails long before we get beyond 127-th code point:
float('infinity')
inf
What do infer from that? That the definition is wrong, or the code is
On Sun, Nov 28, 2010 at 6:03 PM, Martin v. Löwis mar...@v.loewis.de wrote:
..
Note that the support in float() (and the other numeric constructors)
to work with Unicode code points was explicitly added when Unicode
support was added to Python and has been available since Python 1.6.
That
On Sun, Nov 28, 2010 at 6:08 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Am 29.11.2010 00:01, schrieb Alexander Belopolsky:
On Sun, Nov 28, 2010 at 5:56 PM, Martin v. Löwis mar...@v.loewis.de
wrote:
..
This definition fails long before we get beyond 127-th code point:
float('infinity')
On Sun, Nov 28, 2010 at 6:19 PM, Martin v. Löwis mar...@v.loewis.de wrote:
..
You can see the Unicode Consortium's stability policy at
http://unicode.org/policies/stability_policy.html
From the link above:
As more experience is gathered in implementing the characters,
adjustments in the
float('١٢٣٤.٥٦')
1234.56
Even if this is somehow an accident or something that someone snuck in,
I think it a good idea that *users* be able to input amounts with their
native digits. That is different from requiring *programmers* to write
literals with euro-ascii-digits
So one question
What makes it worse, is that while superficially, Unicode versions
follow the same X.Y.Z format as Python versions, the stability
promises are completely different. For example, it appears that the
general category for the ZERO WIDTH SPACE was changed in Unicode
4.0.1. I don't think a
2010/11/28 M.-A. Lemburg m...@egenix.com:
Martin v. Löwis wrote:
float('١٢٣٤.٥٦')
1234.56
I think it's a bug that this works. The definition of the float builtin says
Convert a string or a number to floating point. If the argument is a
string, it must contain a possibly signed decimal or
I have now completed
http://www.python.org/dev/peps/pep-0384/
Benjamin has volunteered to rule on this PEP.
Please comment with any changes you want to see, or speak in
favor or against this PEP.
Regards,
Martin
___
Python-Dev mailing list
On 28/11/2010 23:33, Martin v. Löwis wrote:
float('١٢٣٤.٥٦')
1234.56
Even if this is somehow an accident or something that someone snuck in,
I think it a good idea that *users* be able to input amounts with their
native digits. That is different from requiring *programmers* to write
literals
On Sun, Nov 28, 2010 at 6:03 PM, Martin v. Löwis mar...@v.loewis.de wrote:
..
No no no. Addition of Unicode identifiers has a well-designed,
deliberate specification, with a PEP and all. The support for
non-ASCII digits in float appears to be ad-hoc, and not founded
on actual needs of actual
FWIW the C# equivalent is locale aware *unless* you pass in a specific
culture.
(System.Double.Parse):
That's not quite the equivalent of float(), I would say: this one
apparently is locale-aware, so it is more the equivalent of locale.atof.
The next question then is if it supports
On Sun, 28 Nov 2010 17:23:01 -0600
Benjamin Peterson benja...@python.org wrote:
2010/11/28 M.-A. Lemburg m...@egenix.com:
Martin v. Löwis wrote:
float('١٢٣٤.٥٦')
1234.56
I think it's a bug that this works. The definition of the float builtin
says
Convert a string or a number
Am 29.11.2010 00:56, schrieb Alexander Belopolsky:
On Sun, Nov 28, 2010 at 6:03 PM, Martin v. Löwis mar...@v.loewis.de wrote:
..
No no no. Addition of Unicode identifiers has a well-designed,
deliberate specification, with a PEP and all. The support for
non-ASCII digits in float appears to be
On Sun, Nov 28, 2010 at 6:59 PM, Martin v. Löwis mar...@v.loewis.de wrote:
..
The next question then is if it supports indo-arabic digits in any
locale (or more specifically in an arabic locale).
And once you answered that question, does it support Devanagari or
Bengali digits? And if so, an
On Sun, Nov 28, 2010 at 7:01 PM, Antoine Pitrou solip...@pitrou.net wrote:
..
That's different. Python doesn't assign any semantic meaning to the
characters in identifiers. The non-latin support for numerals, though,
could change the meaning of a program dramatically and needs to be
On 28/11/2010 23:59, Martin v. Löwis wrote:
FWIW the C# equivalent is locale aware *unless* you pass in a specific
culture.
(System.Double.Parse):
That's not quite the equivalent of float(), I would say: this one
apparently is locale-aware, so it is more the equivalent of locale.atof.
Right.
On 29/11/2010 00:04, Alexander Belopolsky wrote:
On Sun, Nov 28, 2010 at 6:59 PM, Martin v. Löwismar...@v.loewis.de wrote:
..
The next question then is if it supports indo-arabic digits in any
locale (or more specifically in an arabic locale).
And once you answered that question, does it
On Mon, Nov 29, 2010 at 2:28 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
For wrapping mutable types I'm tempted to say YAGNI. For the standard
library wrapping integers meets almost all our use-cases except for one
float. (At work we have a decimal constant as it happens.) Perhaps we
Alexander Belopolsky alexander.belopol...@gmail.com writes:
On Sun, Nov 28, 2010 at 7:01 PM, Antoine Pitrou solip...@pitrou.net wrote:
Perhaps int(), float(), Decimal() and friends could take an optional
parameter indicating whether non-ascii digits are considered. It
would then satisfy
On 29/11/2010 00:48, Nick Coghlan wrote:
On Mon, Nov 29, 2010 at 2:28 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
For wrapping mutable types I'm tempted to say YAGNI. For the standard
library wrapping integers meets almost all our use-cases except for one
float. (At work we have a
On 11/28/2010 6:40 PM, Martin v. Löwis wrote:
I have now completed
http://www.python.org/dev/peps/pep-0384/
The current text contains several error messages like:
System Message: WARNING/2 (pep-0384.txt, line 194)
Bullet list ends without a blank line; unexpected unindent.
Terry Jan Reedy
Martin v. Löwis wrote:
float('١٢٣٤.٥٦')
1234.56
I think it's a bug that this works. The definition of the float builtin says
[...]
I think that's a documentation bug rather than a coding bug. If Python
wishes to limit the digits allowed in numeric *literals* to ASCII 0...9,
that's one
On 28/11/2010 21:23, Greg Ewing wrote:
Rob Cliffe wrote:
But couldn't they be presented to the Python programmer as a single
type, with the implementation details hidden under the hood?
Not in CPython, because tuple items are kept in the same block
of memory as the object header. Because
On Sun, Nov 28, 2010 at 7:55 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
..
Of course it is fun that Python can process Bengali numerals, but so
would be allowing Roman numerals. There is a reason why after careful
consideration, PEP 313 was ultimately rejected.
Rejecting a proposed
Steven D'Aprano st...@pearwood.info writes:
If Python wishes to limit the digits allowed in numeric *literals* to
ASCII 0...9, that's one thing, but I think that the digits allowed in
numeric *strings* should allow the full range of digits supported by
the Unicode standard.
I assume you
Alexander Belopolsky wrote:
Two recently reported issues brought into light the fact that Python
language definition is closely tied to character properties maintained
by the Unicode Consortium. [1,2] For example, when Python switches to
Unicode 6.0.0 (planned for the upcoming 3.2 release), we
On Sun, Nov 28, 2010 at 6:43 PM, Steven D'Aprano st...@pearwood.info wrote:
..
is more important than to assure users that once their program
accepted some text as a number, they can assume that the text is
ASCII.
Seems like a pretty foolish assumption, if you ask me, pretty much akin to
On 11/27/2010 04:51 AM, Nick Coghlan wrote:
x = named_value(FOO, 1)
y = named_value(BAR, Hello World!)
z = named_value(BAZ, dict(a=1, b=2, c=3))
print(x, y, z, sep=\n)
print(\n.join(map(repr, (x, y, z
print(\n.join(map(str, map(type, (x, y, z)
set_named_values(globals(),
M.-A. Lemburg writes:
It is not uncommon for Asians and other non-Latin script users to
use their own native script symbols for numbers.
Japanese don't, in computational or scientific work where float()
would be used. Japanese numerals are used for dates and for certain
felicitous ages (and
On Mon, Nov 29, 2010 at 1:39 PM, Stephen J. Turnbull step...@xemacs.org wrote:
I agree that Python should make it easy for the programmer to get
numerical values of native numeric strings, but it's not at all clear
to me that there is any point to having float() recognize them by
default.
Perhaps int(), float(), Decimal() and friends could take an optional
parameter indicating whether non-ascii digits are considered. It would
then satisfy all parties.
Not really. I still would want to see what the actual requirement is:
i.e. do any users actually have the desire to have these
The former ensures that literals in code are always readable; the later
allows users to enter numbers in their own number system. How could that
be a bad thing?
It's YAGNI, feature bloat. It gives the illusion of supporting something
that actually isn't supported very well (namely, parsing
That's mostly irrelevant. This feature exists and someone, somewhere,
may be using it. We normally don't remove stuff without deprecation.
Sure: it should be deprecated before being removed.
Regards,
Martin
___
Python-Dev mailing list
2010/11/29 Martin v. Löwis mar...@v.loewis.de
I have now completed
http://www.python.org/dev/peps/pep-0384/
was structseq.h considered?
IMO it could be made PEP384-compliant with two additions that would replace
two non-compliant functions:
- A new function to create types, since
59 matches
Mail list logo
