2010/11/29 "Martin v. Löwis"
> 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 PyStructSequence_InitTyp
> 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
Python-Dev@pyt
> 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 l
> 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
On Mon, Nov 29, 2010 at 1:39 PM, Stephen J. Turnbull 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.
Indeed, as someone
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 (an
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(),
On Sun, Nov 28, 2010 at 6:43 PM, Steven D'Aprano 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
> assuming that
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 w
Steven D'Aprano 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 specifically mean th
On Sun, Nov 28, 2010 at 7:55 PM, Ben Finney 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 *new* capability is a d
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
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 thin
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 Reed
On 29/11/2010 00:48, Nick Coghlan wrote:
On Mon, Nov 29, 2010 at 2:28 AM, Michael Foord
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.
Alexander Belopolsky writes:
> On Sun, Nov 28, 2010 at 7:01 PM, Antoine Pitrou wrote:
> > Perhaps int(), float(), Decimal() and friends could take an optional
> > parameter indicating whether non-ascii digits are considered. It
> > would then satisfy all parties.
>
> What parties? I don't think
On Mon, Nov 29, 2010 at 2:28 AM, Michael Foord
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 could
> require immutable
> > Perhaps int(), float(), Decimal() and friends could take an optional
> > parameter indicating whether non-ascii digits are considered. It would
> > then satisfy all parties.
>
> What parties? I don't think anyone has claimed to actually have used
> non-ASCII digits with float().
Have you do
On 29/11/2010 00:04, Alexander Belopolsky wrote:
On Sun, Nov 28, 2010 at 6:59 PM, "Martin v. Löwis" 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
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 Sun, Nov 28, 2010 at 7:01 PM, Antoine Pitrou 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
>> well-specified. Whethe
On Sun, Nov 28, 2010 at 6:59 PM, "Martin v. Löwis" 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 arbitrary mix of
Am 29.11.2010 00:56, schrieb Alexander Belopolsky:
> On Sun, Nov 28, 2010 at 6:03 PM, "Martin v. Löwis" 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,
On Sun, 28 Nov 2010 17:23:01 -0600
Benjamin Peterson wrote:
> 2010/11/28 M.-A. Lemburg :
> >
> >
> > "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 numbe
> 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 indo-ara
On Sun, Nov 28, 2010 at 6:03 PM, "Martin v. Löwis" 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 users.
>
I wo
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
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
Python-Dev@
2010/11/28 M.-A. Lemburg :
>
>
> "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
> 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 c
>>> 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
On Sun, Nov 28, 2010 at 6:19 PM, "Martin v. Löwis" 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 properties ma
On Sun, Nov 28, 2010 at 6:08 PM, "Martin v. Löwis" wrote:
> Am 29.11.2010 00:01, schrieb Alexander Belopolsky:
>> On Sun, Nov 28, 2010 at 5:56 PM, "Martin v. Löwis"
>> wrote:
>> ..
This definition fails long before we get beyond 127-th code point:
>>> float('infinity')
inf
>>>
On Sun, Nov 28, 2010 at 6:03 PM, "Martin v. Löwis" 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 doesn't neces
Am 29.11.2010 00:01, schrieb Alexander Belopolsky:
> On Sun, Nov 28, 2010 at 5:56 PM, "Martin v. Löwis" 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 i
+1 on all point below.
On Sun, Nov 28, 2010 at 6:03 PM, "Martin v. Löwis" 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
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 ::= "0"..
>> 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 ::
On Sun, Nov 28, 2010 at 5:56 PM, "Martin v. Löwis" 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 is
On 11/28/2010 3:58 PM, Alexander Belopolsky wrote:
On Sun, Nov 28, 2010 at 3:43 PM, Antoine Pitrou 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 idea that *users* be a
Am 28.11.2010 23:31, schrieb Alexander Belopolsky:
> On Sun, Nov 28, 2010 at 5:17 PM, "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 argum
On Sun, Nov 28, 2010 at 5:42 PM, M.-A. Lemburg 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
http://docs.python.org/dev/py3
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)
"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,
On Sun, Nov 28, 2010 at 5:17 PM, "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 decima
> 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 argu
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 tha
On Sun, Nov 28, 2010 at 4:12 PM, Joao S. O. Bueno 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:
http://bugs.python.org/issue2382
__
On Sun, Nov 28, 2010 at 7:04 PM, Antoine Pitrou wrote:
> On Sun, 28 Nov 2010 15:58:33 -0500
> Alexander Belopolsky wrote:
>
>> On Sun, Nov 28, 2010 at 3:43 PM, Antoine Pitrou wrote:
>> ..
>> >> For example,
>> >> I don't think that supporting
>> >>
>> >> >>> float('١٢٣٤.٥٦')
>> >> 1234.56
>> >>
On Sun, 28 Nov 2010 15:58:33 -0500
Alexander Belopolsky wrote:
> On Sun, Nov 28, 2010 at 3:43 PM, Antoine Pitrou wrote:
> ..
> >> For example,
> >> I don't think that supporting
> >>
> >> >>> float('١٢٣٤.٥٦')
> >> 1234.56
> >>
> >> is more important than to assure users that once their program
>
On Sun, Nov 28, 2010 at 3:43 PM, Antoine Pitrou 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.
>
> Wh
On Sun, 28 Nov 2010 15:24:37 -0500
Alexander Belopolsky 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 support" means "support th
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 charac
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 reviv
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 d
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 pickleab
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 abo
On 28/11/2010 02:38, Nick Coghlan wrote:
On Sun, Nov 28, 2010 at 9:26 AM, Raymond Hettinger
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 value,
and derives the parent cl
On 26.11.2010 05:11, Jesus Cea wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have installed GDB 7.2 32 bits and 32 bits buildslaves are green.
Nevertheless 64 bits buildslaves are failing test_gdb.
Is there any expectation that a 32 bits GDB be able to debug a 64 bits
python?. If not,
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 th
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
http://mail.py
61 matches
Mail list logo
