On Thu, Dec 2, 2010 at 5:05 PM, terry.reedy python-check...@python.org wrote:
+ If
+ the target directory with the same mode as we specified already exists,
+ raises an :exc:`OSError` exception if *exist_ok* is False, otherwise no
+ exception is raised. If the directory cannot be
Hi Anurag,
Le 25/11/2010 10:24, Anurag Chourasia a écrit :
All,
When I configure python to enable shared libraries, none of the
extensions are getting built during the make step due to this error.
you may want to take a look at the following issue:
http://bugs.python.org/issue941346
On Thu, Dec 2, 2010 at 12:41 PM, raymond.hettinger
python-check...@python.org wrote:
+A more general approach is to arrange the weights in a cumulative
probability
+distribution with :func:`itertools.accumulate`, and then locate the random
value
+with :func:`bisect.bisect`::
+
+
Stephen J. Turnbull:
Here's why: '''print %d %
some_integer''' doesn't now, and never will (unless Kristan gets his
Python 2.8wink), produce Arabic or Han numerals. Not in any
language I know of, not in Microsoft Excel, and definitely not in
Python 2.
While I don't have Excel to test
Am 01.12.2010 23:39, schrieb Martin v. Löwis:
As of today, What’s New In Python 3.2 [1] does not even mention the
unicodedata upgrade to 6.0.0.
One reason was that I was instructed not to change What's New a few
years ago.
Maybe all past, present and future whatsnew maintainers can agree on
Hey
We discussed with Eric about the debugging workflow and we agreed that
our life would be easier if every bug fix would land first in
Distutils2 when it makes sense, then get backported to Distutils1.
For other core-devs that would mean that your patches should be done
against
2010/12/2 Stephen J. Turnbull step...@xemacs.org:
Because that works, but
print(T1234)
doesn't (it prints ASCII). You can't round-trip, but users will
want/expect that.
You should be able to round-trip, absolutely. I don't think you should
expect print() to do that. str(56) possibly. :)
On Wed, 1 Dec 2010 22:28:49 -0500
Alexander Belopolsky alexander.belopol...@gmail.com wrote:
Both my personal observations when travelling from Turkey to India and
Wikipedia say yes. When representing a number in Arabic, the lowest-valued
position is placed on the right, so the order of
On Wed, Dec 1, 2010 at 20:17, Antoine Pitrou solip...@pitrou.net wrote:
And I'm not sure what this package called Python is (“a high-level
object-oriented programming language”? like Java?), but I'm pretty sure
I've heard there's a Python 3 compatible version.
Uhm...
Hi Sebastian,
Thanks for your response.
I looked at http://bugs.python.org/issue941346 earlier. I was referred to
this link by Stefan Krah through another bug that i created at
http://bugs.python.org/issue10555 for this issue.
I confirm that my problem is solved with the Python 2.7.1 release
On Wed, Dec 1, 2010 at 8:45 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Tue, Nov 30, 2010 at 3:13 PM, Antoine Pitrou solip...@pitrou.net wrote:
Oh, about ICU:
Actually, I remember you saying that locale should ideally be replaced
with a wrapper around the ICU library.
On 2010/11/27 5:31, Brian Curtin wrote:
On Fri, Nov 26, 2010 at 14:18, Hirokazu Yamamotoocean-c...@m2.ccsnet.ne.jp
wrote:
On 2010/11/27 5:02, Brian Curtin wrote:
We briefly chatted about this on the os.link
feature issue, but I never found a way around it.
How about implementing
On Dec 1, 2010, at 11:45 PM, Alexander Belopolsky wrote:
On Tue, Nov 30, 2010 at 3:13 PM, Antoine Pitrou solip...@pitrou.net wrote:
Oh, about ICU:
Actually, I remember you saying that locale should ideally be replaced
with a wrapper around the ICU library.
By that, I stand - however,
On Thu, Dec 2, 2010 at 8:36 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 1 Dec 2010 22:28:49 -0500
Alexander Belopolsky alexander.belopol...@gmail.com wrote:
..
This matches my limited research on this topic as well. However, I am
not sure that when these codes are embedded in Arabic
Le jeudi 02 décembre 2010 à 11:41 -0500, Alexander Belopolsky a écrit :
Note that my point is not to find the correct answer here, but to
demonstrate that we as a group don't have the expertise to get parsing
of Arabic text right.
I don't understand why you think Arabic or Hebrew text is any
2010/12/2 Guido van Rossum gu...@python.org:
On Wed, Dec 1, 2010 at 8:45 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Tue, Nov 30, 2010 at 3:13 PM, Antoine Pitrou solip...@pitrou.net wrote:
Oh, about ICU:
Actually, I remember you saying that locale should ideally be
On 12/2/2010 4:32 AM, Nick Coghlan wrote:
On Thu, Dec 2, 2010 at 5:05 PM, terry.reedypython-check...@python.org wrote:
(except I did not write most of the patch)
+ If
+ the target directory with the same mode as we specified already exists,
+ raises an :exc:`OSError` exception if
At 07:47 AM 12/2/2010 -0800, Guido van Rossum wrote:
On Wed, Dec 1, 2010 at 8:45 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Tue, Nov 30, 2010 at 3:13 PM, Antoine Pitrou
solip...@pitrou.net wrote:
Oh, about ICU:
Actually, I remember you saying that locale should
On 12/2/2010 8:36 AM, Lennart Regebro wrote:
On Wed, Dec 1, 2010 at 20:17, Antoine Pitrousolip...@pitrou.net wrote:
And I'm not sure what this package called Python is (“a high-level
object-oriented programming language”? like Java?), but I'm pretty sure
I've heard there's a Python 3
On Thu, Dec 2, 2010 at 11:56 AM, Antoine Pitrou solip...@pitrou.net wrote:
Le jeudi 02 décembre 2010 à 11:41 -0500, Alexander Belopolsky a écrit :
Note that my point is not to find the correct answer here, but to
demonstrate that we as a group don't have the expertise to get parsing
of Arabic
Le jeudi 02 décembre 2010 à 13:14 -0500, Alexander Belopolsky a écrit :
I don't understand why you think Arabic or Hebrew text is any different
from Western text. Surely right-to-left isn't more conceptually
complicated than left-to-right, is it?
No, but a mix of LTR and RTL is
On Dec 02, 2010, at 12:59 PM, Terry Reedy wrote:
On 12/2/2010 8:36 AM, Lennart Regebro wrote:
On Wed, Dec 1, 2010 at 20:17, Antoine Pitrousolip...@pitrou.net wrote:
And I'm not sure what this package called Python is (“a high-level
object-oriented programming language”? like Java?), but I'm
On 2010-12-01, at 11:02 AM, Brian Curtin wrote:
http://onpython3yet.com/ might be helpful to you. It orders the projects on
PyPI with the most dependencies which are not yet ported to 3.x.
Note that there are a number of false positives, e.g., the first result --
NumPy, since people
Am 02.12.2010 03:01, schrieb Ben Finney:
Stephen J. Turnbull step...@xemacs.org writes:
Furthermore, he provided good *objective* reason (excessive cost, to
which I can also testify, in several different input methods for
Japanese) why numbers simply would not be input that way.
What's
Maybe all past, present and future whatsnew maintainers can agree on these
rules, which I copied directly from whatsnew/3.2.rst?
I don't think all past maintainers can (I'm pretty certain that AMK
would disagree), but if that's the current policy, I can certainly try
following it (I didn't know
Aside: how does one log into the Cheeseshop with your Launchpad OpenID? When
I try to do it I end up on a Manual user registration page. I fill out the
username with what I think my PyPI user name is, and add my python.org email
address, but then it tells me 'barry' is already taken. Do I
On Dec 02, 2010, at 08:44 PM, Martin v. Löwis wrote:
Since the barry account already exists, you first need to log into
that (likely using a password). You can then claim the LP OpenID as
being associated with that account, and use LP in the future.
Thanks Martin.
-Barry
signature.asc
Hi,
Since discussion has trailed off without any blocking objections, I'm
accepting PEP 384. Martin, you may mark the PEP accepted and proceed
with merging the implementation for the beta on Saturday.
--
Regards,
Benjamin
___
Python-Dev mailing list
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 | intpart .
exponentfloat ::= (intpart | pointfloat) exponent
intpart
Am 02.12.2010 20:40, schrieb Martin v. Löwis:
Maybe all past, present and future whatsnew maintainers can agree on these
rules, which I copied directly from whatsnew/3.2.rst?
I don't think all past maintainers can
Yes, and the same goes for the future ones, since they may not even know yet
Am 02.12.2010 20:06, schrieb Barry Warsaw:
On Dec 02, 2010, at 12:59 PM, Terry Reedy wrote:
On 12/2/2010 8:36 AM, Lennart Regebro wrote:
On Wed, Dec 1, 2010 at 20:17, Antoine Pitrousolip...@pitrou.net wrote:
And I'm not sure what this package called Python is (“a high-level
object-oriented
Then these users should speak up and indicate their need, or somebody
should speak up and confirm that there are users who actually want
'١٢٣٤.٥٦' to denote 1234.56. To my knowledge, there is no writing
system in which '١٢٣٤.٥٦e4' means 12345600.0.
I'm not sure what you're after here.
That
Since discussion has trailed off without any blocking objections, I'm
accepting PEP 384. Martin, you may mark the PEP accepted and proceed
with merging the implementation for the beta on Saturday.
Thanks! will do (I'll also take into consideration the proposed changes).
Regards,
Martin
On Thu, Dec 2, 2010 at 20:24, Sridhar Ratnakumar
sridh...@activestate.com wrote:
Also note that the dependency information is incomplete.
Also, a python3 version of chardet is available (from the website
only, looks like).
Cheers,
Dirkjan
___
On Thu, Dec 2, 2010 at 9:24 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Since discussion has trailed off without any blocking objections, I'm
accepting PEP 384. Martin, you may mark the PEP accepted and proceed
with merging the implementation for the beta on Saturday.
Thanks! will do (I'll
Am 02.12.2010 21:48, schrieb Tarek Ziadé:
On Thu, Dec 2, 2010 at 9:24 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Since discussion has trailed off without any blocking objections, I'm
accepting PEP 384. Martin, you may mark the PEP accepted and proceed
with merging the implementation for the
2010/12/2 Martin v. Löwis mar...@v.loewis.de:
Am 02.12.2010 21:48, schrieb Tarek Ziadé:
On Thu, Dec 2, 2010 at 9:24 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Since discussion has trailed off without any blocking objections, I'm
accepting PEP 384. Martin, you may mark the PEP accepted and
Martin v. Löwis wrote:
[...]
For direct entry by an interactive user, yes. Why are some people in
this discussion thinking only of direct entry by an interactive user?
Ultimately, somebody will have entered the data.
I don't think you really believe that all data processed by a
computer was
So the question still stands: Why not implementing this in Distutils2 ?
Because it then wouldn't be available in Python 3.2, which is the target
release of the PEP.
If that really causes too much pain, I'll refrain from making any
changes to distutils; PEP 384 doesn't specify any changes,
Arabic numerals are being used a lot nowadays in Asian countries,
but that doesn't mean that the native script versions are not
being used anymore.
I never claimed that people are not using their local scripts to enter
numbers. However, none of your examples is about Chinese numerals using
an
Martin v. Löwis wrote:
Then these users should speak up and indicate their need, or somebody
should speak up and confirm that there are users who actually want
'١٢٣٤.٥٦' to denote 1234.56. To my knowledge, there is no writing
system in which '١٢٣٤.٥٦e4' means 12345600.0.
I'm not sure what
2010/12/2 Martin v. Löwis mar...@v.loewis.de:
So the question still stands: Why not implementing this in Distutils2 ?
Because it then wouldn't be available in Python 3.2, which is the target
release of the PEP.
The exact feature I am mentioning is the ability to compile extensions
with new
On Thu, Dec 2, 2010 at 1:55 PM, Antoine Pitrou solip...@pitrou.net wrote:
..
I don't think so. str.split() and str.splitlines() are also defined in
conformance to the SPEC, AFAIK. They certainly try to.
You are joking, right? Where exactly does Unicode specify something like this:
Le jeudi 02 décembre 2010 à 16:34 -0500, Alexander Belopolsky a écrit :
On Thu, Dec 2, 2010 at 1:55 PM, Antoine Pitrou solip...@pitrou.net wrote:
..
I don't think so. str.split() and str.splitlines() are also defined in
conformance to the SPEC, AFAIK. They certainly try to.
You are
I was told not to touch to Distutils code to avoid any regression
since it's patched to the bones in third party products. So we decided
to freeze distutils and add all new features in Distutils2, which is
at alpha stage now. So this move seems contradictory to me.
I think it was a bad
Am 02.12.2010 22:30, schrieb Steven D'Aprano:
Martin v. Löwis wrote:
Then these users should speak up and indicate their need, or somebody
should speak up and confirm that there are users who actually want
'١٢٣٤.٥٦' to denote 1234.56. To my knowledge, there is no writing
system in which
On Thu, Dec 2, 2010 at 4:14 PM, M.-A. Lemburg m...@egenix.com wrote:
..
Have you tried Google ?
I tried google at I could not find any plain text or HTML file that
would use Arabic-Indic numerals. What was interesting, though that a
search for quran unicode (without quotes). Brought me to
2010/12/2 Martin v. Löwis mar...@v.loewis.de:
I was told not to touch to Distutils code to avoid any regression
since it's patched to the bones in third party products. So we decided
to freeze distutils and add all new features in Distutils2, which is
at alpha stage now. So this move seems
On 02/12/2010 21:39, Martin v. Löwis wrote:
I was told not to touch to Distutils code to avoid any regression
since it's patched to the bones in third party products. So we decided
to freeze distutils and add all new features in Distutils2, which is
at alpha stage now. So this move seems
On Thu, Dec 2, 2010 at 8:23 PM, Martin v. Löwis mar...@v.loewis.de wrote:
In the case of number parsing, I think Python would be better if
float() rejected non-ASCII strings, and any support for such parsing
should be redone correctly in a different place (preferably along with
printing of
On 12/2/2010 4:48 PM, Martin v. Löwis wrote:
Am 02.12.2010 22:30, schrieb Steven D'Aprano:
Martin v. Löwis wrote:
Then these users should speak up and indicate their need, or somebody
should speak up and confirm that there are users who actually want
'١٢٣٤.٥٦' to denote 1234.56. To my
This freeze made the situation worse.
Can you extend on this and explains why it makes it worse ?
Before the freeze, distutils was unmaintained (i.e. before you started
maintaining it), but people who want to improve it gradually atleast
could. Now gradual improvements are also banned, so
Am 02.12.2010 22:54, schrieb Michael Foord:
On 02/12/2010 21:39, Martin v. Löwis wrote:
I was told not to touch to Distutils code to avoid any regression
since it's patched to the bones in third party products. So we decided
to freeze distutils and add all new features in Distutils2, which is
2010/12/2 Martin v. Löwis mar...@v.loewis.de:
Am 02.12.2010 22:54, schrieb Michael Foord:
On 02/12/2010 21:39, Martin v. Löwis wrote:
I was told not to touch to Distutils code to avoid any regression
since it's patched to the bones in third party products. So we decided
to freeze distutils
The distutils is unmaintained situation. It's not only unmaintained
now, but proposed improvements are rejected without consideration, on
the grounds that they are changes.
I welcome those changes in Distutils2. That's the whole point.
That would be useful if there was a clear vision of
Eric Smith wrote:
The current behavior should go nowhere; it is not useful. Something very
similar to the current behavior (but done correctly) should go into the
locale module.
I agree with everything Martin says here. I think the basic premise is:
you won't find strings in the wild that
2010/12/2 Martin v. Löwis mar...@v.loewis.de:
This freeze made the situation worse.
Can you extend on this and explains why it makes it worse ?
Before the freeze, distutils was unmaintained (i.e. before you started
maintaining it), but people who want to improve it gradually atleast
could.
On Thu, 02 Dec 2010 23:21:25 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
Am 02.12.2010 22:54, schrieb Michael Foord:
On 02/12/2010 21:39, Martin v. Löwis wrote:
I was told not to touch to Distutils code to avoid any regression
since it's patched to the bones in third party products. So
2010/12/2 Martin v. Löwis mar...@v.loewis.de:
The distutils is unmaintained situation. It's not only unmaintained
now, but proposed improvements are rejected without consideration, on
the grounds that they are changes.
I welcome those changes in Distutils2. That's the whole point.
That
On Dec 02, 2010, at 11:21 PM, Martin v. Löwis wrote:
Well, the PEP 384 text in PEP 3149 specifies a change. It's not clear
whether this change was accepted when PEP 3149 was accepted, or whether
it was accepted when PEP 384 was accepted, or whether it was not
accepted at all, or whether it was
No, only the ones that didn't cause backwards incompatibilities,
and broke existing packages.
This is impossible. I can point you to some third party project that
can break if you touch some distutils internals, like setuptools.
Setuptools also uses some privates global variables in some
Alexander Belopolsky wrote:
On Thu, Dec 2, 2010 at 4:14 PM, M.-A. Lemburg m...@egenix.com wrote:
..
Have you tried Google ?
I tried google at I could not find any plain text or HTML file that
would use Arabic-Indic numerals. What was interesting, though that a
search for quran unicode
Terry Reedy wrote:
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
I think distutils is simply a bugfix branch for distutils2. Similarly
as how we don't commit improvements in e.g. 2.7 or 3.1, neither do we
commit improvements to distutils.
It's different, though, in the sense that Python has a release schedule
and multiple committers working on it, and that
On Thu, Dec 2, 2010 at 5:58 PM, M.-A. Lemburg m...@egenix.com wrote:
..
I will change my mind on this issue when you present a
machine-readable file with Arabic-Indic numerals and a program capable
of reading it and show that this program uses the same number parsing
algorithm as Python's
Am 02.12.2010 23:43, schrieb M.-A. Lemburg:
Eric Smith wrote:
The current behavior should go nowhere; it is not useful. Something very
similar to the current behavior (but done correctly) should go into the
locale module.
I agree with everything Martin says here. I think the basic premise
On 12/2/2010 5:43 PM, M.-A. Lemburg wrote:
Eric Smith wrote:
The current behavior should go nowhere; it is not useful. Something very
similar to the current behavior (but done correctly) should go into the
locale module.
I agree with everything Martin says here. I think the basic premise is:
On 02/12/2010 23:01, Martin v. Löwis wrote:
[snip...]
I'm just getting tired having to talk to
five projects just to make a single change to the build infrastructure
available to the Python community.
The very best hope of resolving that particular problem is distutils2. :-)
distutils2 is
2010/12/2 Martin v. Löwis mar...@v.loewis.de:
No, only the ones that didn't cause backwards incompatibilities,
and broke existing packages.
This is impossible. I can point you to some third party project that
can break if you touch some distutils internals, like setuptools.
Setuptools also
The point is that we support all of Unicode in Python, not just a fragment,
and therefore the numeric constructors support all of Unicode.
That conclusion is as false today as it was in Python 1.6, but only now
people start caring about that.
a) we don't support all of Unicode in numeric
Eric Smith wrote:
On 12/2/2010 5:43 PM, M.-A. Lemburg wrote:
Eric Smith wrote:
The current behavior should go nowhere; it is not useful. Something
very
similar to the current behavior (but done correctly) should go into the
locale module.
I agree with everything Martin says here. I think
From my point of view, the PEP 3149 text is just a proposal. It leaves the
final decision to PEP 384, but tries to address some of the issues raised
during the PEP 3149 discussion. I think it is within PEP 384's scope to make
the final decisions about it.
Ok, then it looks like there just
An alpha is already released. A beta will be released for Pycon (I
need it for my talk :) ) Then hopefully the final before 3.2
Ok, that's promising.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
On Fri, Dec 3, 2010 at 12:01 AM, Martin v. Löwis mar...@v.loewis.de wrote:
I think distutils is simply a bugfix branch for distutils2. Similarly
as how we don't commit improvements in e.g. 2.7 or 3.1, neither do we
commit improvements to distutils.
It's different, though, in the sense that
Hi,
2010/12/3 Michael Foord fuzzy...@voidspace.org.uk
On 02/12/2010 23:01, Martin v. Löwis wrote:
[snip...]
I'm just getting tired having to talk to
five projects just to make a single change to the build infrastructure
available to the Python community.
The very best hope of resolving
On Thu, Dec 2, 2010 at 4:14 PM, M.-A. Lemburg m...@egenix.com wrote:
..
Some examples:
http://www.bdl.gov.lb/circ/intpdf/int123.pdf
I looked at this one more closely. While I cannot understand what it
says, It appears that Arabic numerals are used in dates. It looks
like Python want be able
Stephen J. Turnbull wrote:
Steven D'Aprano writes:
With full respect to haiyang kang, hear-say from one person can hardly
be described as strong evidence
That's *disrespectful* nonsense. What Haiyang reported was not
hearsay, it's direct observation of what he sees around him and
On 02/12/2010 23:51, Amaury Forgeot d'Arc wrote:
Hi,
2010/12/3 Michael Foord fuzzy...@voidspace.org.uk
mailto:fuzzy...@voidspace.org.uk
On 02/12/2010 23:01, Martin v. Löwis wrote:
[snip...]
I'm just getting tired having to talk to
five projects just to make
On Dec 03, 2010, at 12:51 AM, Amaury Forgeot d'Arc wrote:
Sure. But today (before 3.2b1) we want to merge PEP3149 and PEP384;
they change the paths and filenames used by python.
Either we modify distutils to comply with the new names,
or defer these PEPs until distutils2 is ready.
I do not think
On 03.12.2010 00:25, Tarek Ziadé wrote:
2010/12/2 Martin v. Löwismar...@v.loewis.de:
No, only the ones that didn't cause backwards incompatibilities,
and broke existing packages.
This is impossible. I can point you to some third party project that
can break if you touch some distutils
On 12/2/2010 6:54 PM, Alexander Belopolsky wrote:
On Thu, Dec 2, 2010 at 4:14 PM, M.-A. Lemburgm...@egenix.com wrote:
..
Some examples:
http://www.bdl.gov.lb/circ/intpdf/int123.pdf
I looked at this one more closely. While I cannot understand what it
says, It appears that Arabic numerals
even without having any changes in distutils it would make sense to know if
an
extension can be built with the restricted ABI, so maybe it is better to
defer
any changes to the extension soname, and provide a check for an extension if
it
conforms to the restricted ABI, even if the
Martin v. Löwis writes:
Aside: how does one log into the Cheeseshop with your Launchpad OpenID?
When
I try to do it I end up on a Manual user registration page. I fill out
the
username with what I think my PyPI user name is, and add my python.org
email
address, but then
Lennart Regebro writes:
2010/12/2 Stephen J. Turnbull step...@xemacs.org:
T1000 = float('一.◯◯◯')
That was already discussed here, and it's clear that unicode does not
consider these characters to be something you can use in a decimal
number, and hence it's not broken.
Huh? IOW,
Hi Prashant,
Python 3 support in distutils2 is not entirely finished, it’s an
interesting and challenging task.
Another idea: convert the python.org internal scripts to use Python 3,
for example starting with patches for http://code.python.org/hg/peps/ .
This would not have any impact on the
Furthermore, data can well originate from texts that were written
hundreds or even thousands of years ago, so there is plenty of
material available for processing.
humm..., for this, i think we need a special tuned language
processing system to handle this, and one subsystem for one language
Neil Hodgson writes:
While I don't have Excel to test with, OpenOffice.org Calc will
display in Arabic or Han numerals using the NatNum format codes.
Display is different from input, but at least this is concrete
evidence.
Will it accept Arabic on input? (Han might be too much to ask
Antoine Pitrou writes:
The legacy format argument looks like a red herring to me. When
converting from a format to another it is the programmer's job to
his/her job right.
Uhmm, the argument *for* this feature proposed by several people
is that Python's numeric constructors do it
On Thu, Dec 2, 2010 at 4:57 PM, Mark Dickinson dicki...@gmail.com wrote:
..
(the decimal spec requires that non-European digits be accepted).
Mark,
I think *requires* is too strong of a word to describe what the spec
says. The decimal module documentation refers to two authorities:
1. IBM’s
Le 02/12/2010 23:17, Martin v. Löwis a écrit :
Before the freeze, distutils was unmaintained (i.e. before you started
maintaining it), but people who want to improve it gradually atleast
could. Now gradual improvements are also banned, so it's not only
unmaintained, but I can't even provide
Hi everyone,
I have sketched a workflow guide on
http://wiki.python.org/moin/Distutils/FixingBugs
Cheers
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Python’s setup.py has an example in Martin’s branch:
ext = Extension('xxlimited', ['xxlimited.c'],
define_macros=[('Py_LIMITED_API', 1)])
http://codereview.appspot.com/3262043/patch/1/68
This is possible with today’s distutils. I don’t know if it’s enough to
build
I wonder what your definition of “unmaintained” is.
In this specific case: doesn't get feature requests acted upon.
I'm well aware that you are fixing bugs, and that is appreciated.
Sure, distutils is not as well-maintained as other modules, but a dozen
bugs have been fixed by five or six of
It would be nice if the UI told users that, and offered an opportunity
to log in.
Better yet would be a option for an OpenID to claim a user name by
giving the password for it (ie, automatically on a successful login
from that page).
So many projects, so little time. Contributions are
94 matches
Mail list logo
