I have now completed
http://www.python.org/dev/peps/pep-0384/
was structseq.h considered?
No, it wasn't - unfortunately, it still doesn't get included when
including Python.h. I'll add it.
IMO it could be made PEP384-compliant with two additions that would
replace two
Alexander Belopolsky wrote:
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.
Am 29.11.2010 09:09, schrieb Martin v. Löwis:
I have now completed
http://www.python.org/dev/peps/pep-0384/
was structseq.h considered?
No, it wasn't - unfortunately, it still doesn't get included when
including Python.h. I'll add it.
Would 3.2 be a good time to finally
Am 28.11.2010 00:58, schrieb Steven D'Aprano:
Georg Brandl wrote:
Am 27.11.2010 23:11, schrieb Steven D'Aprano:
I wasn't able to find a comment bubble that contained anything, so I
don't know what sort of information you expect them to contain -- every
one I tried said 0 comments.
On 29.11.2010 00:40, Martin v. Löwis wrote:
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.
I looked at a diff with r84330 from the py3k
Nick Coghlan wrote:
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
On 25 novembre 11:22, Ron Adam wrote:
On 11/25/2010 08:30 AM, Emile Anclin wrote:
hello,
working on Pylint, we have a lot of voluntary corrupted files to test
Pylint behavior; for instance
$ cat /home/emile/var/pylint/test/input/func_unknown_encoding.py
# -*- coding: IBO-8859-1 -*-
On Mon, Nov 29, 2010 at 9:02 PM, M.-A. Lemburg m...@egenix.com wrote:
If we would go down that road, we would also have to disable other
Unicode features based on locale, e.g. whether to apply non-ASCII
case mappings, what to consider whitespace, etc.
We don't do that for a good reason:
Hello,
Please comment with any changes you want to see, or speak in
favor or against this PEP.
How to get a diff between py3k and this branch?
Regards
___
Python-Dev mailing list
Python-Dev@python.org
On 29.11.2010 14:14, Éric Araujo wrote:
Hello,
Please comment with any changes you want to see, or speak in
favor or against this PEP.
How to get a diff between py3k and this branch?
I used
svn diff svn://svn.python.org/python/branches/p...@84330
On Mon, Nov 29, 2010 at 11:37 PM, Matthias Klose d...@ubuntu.com wrote:
On 29.11.2010 14:14, Éric Araujo wrote:
Hello,
Please comment with any changes you want to see, or speak in
favor or against this PEP.
How to get a diff between py3k and this branch?
I used
svn diff
On Mon, Nov 29, 2010 at 9:40 AM, Martin v. Löwis mar...@v.loewis.de wrote:
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.
This is probably
On Mon, 29 Nov 2010 13:58:05 +1000
Nick Coghlan ncogh...@gmail.com wrote:
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
On Sun, 28 Nov 2010 21:32:15 -0500
Alexander Belopolsky alexander.belopol...@gmail.com wrote:
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
On Nov 29, 2010, at 8:58 AM, Nick Coghlan wrote:
The http read only URLs
didn't work (no diff returned, just svn: OPTIONS of
'http://svn.python.org/python/branches/pep-0384': 200 OK
(http://svn.python.org)),
That was the wrong url: you should've used
Nick Coghlan wrote:
On Mon, Nov 29, 2010 at 9:02 PM, M.-A. Lemburg m...@egenix.com wrote:
If we would go down that road, we would also have to disable other
Unicode features based on locale, e.g. whether to apply non-ASCII
case mappings, what to consider whitespace, etc.
We don't do that for
On Mon, Nov 29, 2010 at 11:24 AM, Matthias Klose d...@ubuntu.com wrote:
On 29.11.2010 00:40, Martin v. Löwis wrote:
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
On Mon, Nov 29, 2010 at 3:52 AM, Georg Brandl g.bra...@gmx.net wrote:
..
Yes, I failed to fully read the instructions you sent, or understand
them. That's what users do -- they don't read your instructions, and
they misunderstand them. If your UI isn't easily discoverable, users
will not be
On Mon, Nov 29, 2010 at 2:22 AM, Martin v. Löwis mar...@v.loewis.de wrote:
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
On Mon, 29 Nov 2010 08:22:46 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
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
Alexander Belopolsky wrote:
On Mon, Nov 29, 2010 at 2:22 AM, Martin v. Löwis mar...@v.loewis.de wrote:
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.
On Mon, Nov 29, 2010 at 03:53, Sylvain Thénault
sylvain.thena...@logilab.fr wrote:
On 25 novembre 11:22, Ron Adam wrote:
On 11/25/2010 08:30 AM, Emile Anclin wrote:
hello,
working on Pylint, we have a lot of voluntary corrupted files to test
Pylint behavior; for instance
$ cat
On 11/29/2010 10:19 AM, M.-A. Lemburg wrote:
Nick Coghlan wrote:
On Mon, Nov 29, 2010 at 9:02 PM, M.-A. Lemburgm...@egenix.com wrote:
If we would go down that road, we would also have to disable other
Unicode features based on locale, e.g. whether to apply non-ASCII
case mappings, what to
On Mon, Nov 29, 2010 at 1:33 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 29 Nov 2010 08:22:46 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
The former ensures that literals in code are always readable; the later
allows users to enter numbers in their own number system. How could
On Mon, Nov 29, 2010 at 2:23 PM, Terry Reedy tjre...@udel.edu wrote:
..
Since you are the knowledgable advocate of the current behavior, perhaps you
could open an issue and propose a doc patch, even if not .rst formatted.
I am not an advocate of the current behavior, but an issue for doc
- Should the distutils support for LIMITED_API be part of the pep, or
be implemented later?
In any case, it has to be implemented in Distutils2, not in Distutils.
Distutils is frozen and just in maintenance mode.
I think it's too late for that. PEP 3149 is accepted, and it does
specify a
2010/11/29 Martin v. Löwis mar...@v.loewis.de:
- Should the distutils support for LIMITED_API be part of the pep, or
be implemented later?
In any case, it has to be implemented in Distutils2, not in Distutils.
Distutils is frozen and just in maintenance mode.
I think it's too late for
On 11/29/2010 01:22 PM, Brett Cannon wrote:
On Mon, Nov 29, 2010 at 03:53, Sylvain Thénault
sylvain.thena...@logilab.fr wrote:
On 25 novembre 11:22, Ron Adam wrote:
On 11/25/2010 08:30 AM, Emile Anclin wrote:
hello,
working on Pylint, we have a lot of voluntary corrupted files to test
Extensions built with Py_LIMITED_API have the python version encoded in
it's name. Which abi name should be used for these extensions?
PEP 3149, IIUC, says it should be abi3. I don't understand what that
means, though (with respect to, say, distutils)
- The m and u modifiers in the abi name
This is probably an issue independent of the PEP but there appear to
be a *lot* of exposed typedefs for various type slots and other
function signatures that don't start with the Py prefix (i.e. getter,
setter, unaryfunc and friends).
It's indeed independent: the names don't actually affect
Am 29.11.2010 14:14, schrieb Éric Araujo:
Hello,
Please comment with any changes you want to see, or speak in
favor or against this PEP.
How to get a diff between py3k and this branch?
As others have already explained:
svn diff http://svn.python.org/projects/python/branches/p...@84329
Rob Cliffe wrote:
But when a frozen list a.k.a. tuple would be created - either directly,
or by setting a list's mutable flag to False which would really turn it
into a tuple - the size *would* be known.
But at that point the object consists of two memory blocks -- one
containing just the
Am 29.11.2010 19:33, schrieb Antoine Pitrou:
On Mon, 29 Nov 2010 08:22:46 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
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
- Should Python documentation refer to the specific version of Unicode
that it supports?
You mean, mention it somewhere? Sure (although it would be nice if the
documentation generator would automatically extract it from the source,
just as it extracts the Python version number).
Of course,
Am 29.11.2010 09:36, schrieb Georg Brandl:
Am 29.11.2010 09:09, schrieb Martin v. Löwis:
I have now completed
http://www.python.org/dev/peps/pep-0384/
was structseq.h considered?
No, it wasn't - unfortunately, it still doesn't get included when
including Python.h. I'll add it.
I don't see how the grouping can be completely separated
from the value-naming. If the named values are to be
subclassed from the base values, then you want all the
members of a group to belong to the *same* subclass.
You can't get that by treating each named value on its
own and then trying to
Alexander Belopolsky wrote:
Speaking of YAGNI, does anyone want to defend
complex('١٢٣٤.٥٦j')
1234.56j
*If* we allow float('١٢٣٤.٥٦') (as we currently do, but is being
disputed by some), then we should allow complex('١٢٣٤.٥٦j'). It would be
silly for complex to be more restrictive than
On 11/28/2010 09:03 PM, Ron Adam wrote:
It does associate additional info to names and creates a nice dictionary to
reference.
def name_values( FOO: 1,
BAR: Hello World!,
BAZ: dict(a=1, b=2, c=3) ):
... return FOO, BAR, BAZ
...
foo(1,2,3)
(1, 2, 3)
foo.__annotations__
{'BAR': 'Hello
On Tue, Nov 30, 2010 at 12:15 AM, James Y Knight f...@fuhm.net wrote:
On Nov 29, 2010, at 8:58 AM, Nick Coghlan wrote:
The http read only URLs
didn't work (no diff returned, just svn: OPTIONS of
'http://svn.python.org/python/branches/pep-0384': 200 OK
(http://svn.python.org)),
That was
On Tue, Nov 30, 2010 at 7:36 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
I don't see how the grouping can be completely separated
from the value-naming. If the named values are to be
subclassed from the base values, then you want all the
members of a group to belong to the *same*
On Mon, Nov 29, 2010 at 5:09 PM, Steven D'Aprano st...@pearwood.info wrote:
..
But in any case, please don't conflate the question of whether Python should
accept j and/or i for complex numbers with the question of supporting
non-arabic numerals. The two issues are unrelated.
The two issues
M.-A. Lemburg writes:
Just because ASCII-proponents may have a hard time reading such
literals,
That's not the point.
doesn't mean that script users have the same trouble.
The script users may have no trouble reading them, but that doesn't
mean it's not a YAGNI. In Japanese, it's a
Steven D'Aprano writes:
But in any case, please don't conflate the question of whether Python
should accept j and/or i for complex numbers with the question of
supporting non-arabic numerals. The two issues are unrelated.
Different, yes, unrelated, no. They're both about whether variant
Good morning python-dev,
PEP 291 (Backward Compatibility for Standard Library) does not seem to
take Python 3 into account. Is this PEP only relevant for the 2.7
branch?* If it’s supposed to apply to 3.x too, despite the view that
3.0 was a clean break, what does it mean to have a module that
44 matches
Mail list logo
