Am 26.10.2010 22:28, schrieb Peter Ingebretson:
> --- On Tue, 10/26/10, "Martin v. Löwis" wrote:
>> I think this then mandates a PEP; I'm -1 on the feature also.
>
> I am happy to write up a PEP for this feature. I'll start that
> process now, though
> Let’s move the current ‘trunk’ into /branches/afterlife-27. Open it for
> submissions from people such as myself that use 2.7 on a regular basis
> and are willing to give it some extra love. Host it there without the
> usual stringent python quality assurance, buildbot support, release
> manage
> Furthermore, our server is fairly complex: we're using quite some
> libraries to do different jobs, and one of the approaches (not the
> only one) that we're taking to deal with this beast is to analyze its
> memory-related behaviour from an external POV (thinking it as a black
> box).
>
> So, b
> I got no reply concerning those modifications to the buildbot script so
> that I could run 2 slaves on AIX.
I'm really really reluctant here. The proposed/requested changes are
fairly intrusive, even though AIX is just a minority platform. So I need
to find some time to rewrite them, which I hav
> (and, believe me, not having to backport new 3.x features to the 2.x
> branch makes our work much easier than it was; people generally seem
> to underestimate the amount of care needed for such things, especially
> in areas where 2.x is significantly more complex - old-style classes,
> two paral
Am 28.10.2010 18:07, schrieb l...@rmi.net:
> Kristj?n Valur J?nsson writes:
>> James Y Knight said:
>> The python community has already decided many times over that Python2 is
>> dead
>> and Python3 is the future
>>
>> But the patient is very much alive and kicking, no matter what the good
>> d
> Right now, Kristján is burning off his (non-fungible) enthusiasm in this
> discussion rather than addressing more 2.x maintenance issues. If 3.x
> adoption takes off and makes a nice hockey stick graph, then few people
> will care about this in retrospect. In the intervening hypothetical
> half
> Actually I would like code like
> s = socket()
> ...
> header = struct.unpack("i", s)
>
> In other words, struct should interact with files/streams directly, instead
> of
> requiring me to first read a chunk who's size I manually have to determine
> etc.
That is easy to achieve using t
> While maintainers' convenience is a valid valid concern and some level
> of idiosyncrasy is healthy to allow active maintainers to code in
> their preferred style, I think users' convenience should come first
> when it conflicts with that of maintainers. Remember, code is written
> once and read
> It's obvious that a large proportion of the existing python-dev'ers will
> not participate in such a project, but why should we try to stop someone
> else to work on it ?
I propose to stop this discussion of theoretical projects, and only
restart it when someone actually proposes to lead such a
> "Infrastructure" sounds to me like code for "money".
No, it's rather "volunteer time". Of course, people keep proposing
that this should be replaced by hired time that gets paid from
donations, but all such proposals so far got stuck at implementation
details (i.e. it's actual work that nobody h
Am 29.10.2010 21:54, schrieb Barry Warsaw:
> Another quick thought. What would people think about regular timed
> releases if python 2.7? This is probably more a question for
> Benjamin but doing sonmight provide better predictability and
> "customer service" to our users. I might like to see mont
> Right, the effort of those people is obviously the limiting factor
> here. Automating builds sounds like a good step forward. What are the
> sticky bits here? Martin, Ronald, how much of the process is not
> automated, and why is automating hard?
I don't feel like producing a complete list of bu
Am 30.10.2010 14:29, schrieb Dirkjan Ochtman:
> On Sat, Oct 30, 2010 at 14:09, "Martin v. Löwis" wrote:
>> I don't feel like producing a complete list of build steps; the entire
>> process takes about four hours.
>
> So is most of this scripted, or is there
> I think size should be in TCHARs, not in bytes. (MSDN says so)
> And GetComputerName's signature differs from MSDN. (Maybe should
> use GetComputerNameExW again?)
You are right. So how about this patch?
Index: Modules/socketmodule.c
==
> I was happy to find out that the /proc system came from Plan9 because
> I always thought Plan9 was dead water. But in this particular case
> Plan9 outdid System7 in the the realm of "everything is a file" by
> making everything a file.
However, on Plan 9, /proc//fd is not a directory, but a reg
>> def read_and_unpack(stream, format):
>> data = stream.read(struct.calcsize(format))
>> return struct.unpack(format, data)
>>
>>> Otherwise, I'm +1 on your suggestion, avoiding copying is a good
>>> thing.
>>
>> I believe my function also doesn't involve any unnecessary copies.
> You just
> To clarify (but I dont speak for the rest of #python, just myself), I
> think the move was premature, but I don't use Arch and I don't know what
> typical Arch users expect. The reason I think it's premature is that
> 'python2' just doesn't work everywhere, and I would have gone for a
> transitio
Am 06.11.2010 12:19, schrieb Victor Stinner:
> Hi,
>
> I noticed "OSError: [Errno 23] Too many open files in system" errors on your
> FreeBSD buildbot. I would like to know if you configured a limit on the open
> files or maybe of child processes on this buildbot or not, or if it is a
> failure
> But the previous consensus (at least, as I, and presumably many other
> people understood it) was that python2 would remain the owner of the
> name "/usr/bin/python" for the indefinite future, and python3 would
> be invoked with /usr/bin/python3.
Can you cite references for that (not that other
> Remove one trace of Mac OS 9 support (#7908 follow-up)
>
> This was overlooked in r80804. This change is not really a bug fix,
I'm skeptical that this change should be carried out, then.
It's easy to argue that this can't possibly hurt (but I can certainly
come up with code that will break
> This was a private function used on an unsupported platform, this should
> do no harm. We’ve been bitten by “should do no harm” before though, so
> I am ready to revert this change (and learn from this :)
Do as you like. I won't insist on it being reverted.
It's rather a matter of agreeing whe
> sorry in advance if this sounds a little indiscreet, but I think it
> would be great if we'd have SSH access against some of the computers
> used to host buildbots.
The only way this can work is on a bilateral basis. If you need shell
access to one of the build slaves, contact the slave operator
>> It's rather a matter of agreeing when moving forward: IMO, mere style
>> changes, code cleanup etc shouldn't be applied to the bug fix branches,
>> as their only purpose is to provide bug fixes for existing users.
>
> The omission of the deletion from the 5/5 revision was a bug in that
> revisi
Am 07.11.2010 15:57, schrieb James Y Knight:
> On Nov 6, 2010, at 9:41 AM, Martin v. Löwis wrote:
>> So I don't recall a decision that there shouldn't be a python2
>> binary,
>
> The decision to make one would have to be an active decision, since
> Python has ne
Am 07.11.2010 22:05, schrieb MRAB:
> It looks like the bug tracker is down.
Thanks - we have already contacted the hosting company, who have already
contacted the datacenter. It appears that the bug tracker actually
wasn't down (at least, it believes it was up all time), which suggests
that there
> Luckily, the problems that we faced 2.5 years ago when I came up with
> the idea of Snakebite are still just as ever present today ;-)
Is this bashing of existing infrastructure really necessary?
People (like me) might start bashing about vaporware and how
a bird in the hand is worth two in the
> I've spent a good bit of time on that, and left all the instructions in
> the buildbot master config. I also adapted buildbot's hg hook to our
> situation (e.g. to send a change to multiple masters, as required for
> the community buildbots), so it should be quite easy to actually
> switch the b
> That is true, however it doesn't help you: the hook takes its configuration
> from the hgrc file, so you can configure exactly one host:port to send
> changes to.
Ah, ok.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
bugs.python.org is moving to a new hardware; this also involves a new IP
address. The migration will happen on Thursday, likely around 8:00 UTC.
If all goes well, outage should be very short.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.
> How do you support cross-platform code using bytes filenames?
> IIRC, it has already been argued that it was an important feature. Many
> filesystem-related utilities might prefer to handle filenames in bytes
> form.
It would be a policy decision. However, I think it is hear-say that
filesystem-
> Even if I hate the MBCS encoding, because it replaces undecodable characters
> by similar glyphs by default, I'm not certain that it is a good idea to drop
> the bytes API. Can it be a problem to port programs from Python2 to Python3?
> Do major Python2 programs/libraries rely on the bytes API
> Additionally:
>
> d) Over a socket (like the HTTP protocol) -> Bytes.
Sure. However, you can't really expect that the bytes you receive
over the socket are a meaningful filename on your local Windows
installation. So it would be a bug in the application to not decode
the bytes that you receive
As you may have noticed: I updated the buildbot master to release 0.8.2.
If you notice any problems, please post them here.
Slave operators can upgrade their installations at their own pace;
buildbot is highly backwards compatible. As a recommendation, I suggest
that slaves run at least at the ver
bugs.python.org is now on the new hardware. There have been some
problems in the migration: the old hardware would start failing before
the scheduled migration date, so the migration was done early, causing
outage for some people who then the old address in their DNS caches.
In addition, there was
> I'm not talking about Windows obviously. POSIX filenames are natively
> bytes, so if you get a bytes filename from an external source, it makes
> sense to reuse the bytes form.
>
> I think it would be a mistake to allow bytes filenames under POSIX but
> not under Windows. It makes porting harder
> Ok, good answer. In this case, I vote +1 to remove completly the ANSI version
> from all Python modules.
I think caution is still necessary. So I propose to deprecate byte
filenames on Windows in 3.2, with removal in 3.3. People who think this
is a terrible mistake and breaks there applications
> Thanks Martin, for all you do to keep our infrastructure humming along
> smoothly, including the recent Roundup migration.
I just write the announcements :-) In this case. thanks should also
extend to Izak Burger of Upfront Hosting who did most of the setup
(I just did the DNS changes), and to b
> If the code is currently working and isn't a security hole, then we
> obviously don't "have to".
> Apparently several developers "want to", which is different.
In case the motivation for that isn't clear: it would produce a
significant code reduction, and therefore ease maintenance.
Regards,
Ma
> We should also keep in mind that *Microsoft* have chosen to keep the
> bytes Win32 APIs around, despite their flaws, all in the name of
> backwards compatibility.
Of course, Microsoft is in a different position. If they remove a
functionality in some release, their users typically can't go back
> This is a completely separate issue, though probably around just as
> long, and like the popup problem its frequency changes over time. By
> "hung" here I'm referring to cases where something must go wrong with
> a test and/or its cleanup such that a python_d process remains
> running, usually s
Am 14.11.2010 09:25, schrieb Nick Coghlan:
> On Sun, Nov 14, 2010 at 1:10 PM, Terry Reedy wrote:
>> Much better except possible for \n after 'summary:'
>
> That extra line break helps more for multi-line checkin messages
> (which happen reasonably often). Doesn't really bother me either way -
> I
> I suspect my hg-fu is inadequate to at this point - I get an 'access
> to repository "hg.python.org/hooks" not permitted' error when I try to
> push the modified file to "ssh://h...@hg.python.org/hooks".
Try
ssh://h...@hg.python.org/repos/hooks
I think this is something that needs to be fixed:
>> I think this is something that needs to be fixed: I fail to see the
>> point of having this extra repos/ directory in the path (even though
>> it's certainly useful to have them all in a separate directory on disk).
>
> IIUC, "repos/hooks" is interpreted as a relative path to the "hg"
> user's
Am 17.11.2010 08:18, schrieb Georg Brandl:
> Am 16.11.2010 19:38, schrieb Jesus Cea:
>> Is there any updated mercurial schedule?.
>>
>> Any impact related with the new 3.2 schedule (three weeks offset)?
>
> I've been trying to contact Dirkjan and ask; generally, I don't
> see much connection to th
>> Alternatively, b1 should be postponed until after the Mercurial
>> migration is done.
>
> I think this "new feature" is not so shocking that it can be used as
> an argument to hold up the migration. If you have another reason to
> stop the migration please say so; personally I can't wait for it
>> Therefore, I'm concerned that I will have to work out all the details
>> on my own, just so that I can produce the b2 binaries (says); this is
>> not something I look forward to.
>
> How much does the binary build process really depend on version control?
> I.e., what would be stopping you from
Am 19.11.2010 03:23, schrieb Benjamin Peterson:
> 2010/11/18 Jesus Cea :
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 18/11/10 18:32, "Martin v. Löwis" wrote:
>>> In general, I'm *also* concerned about the lack of volunteers that
> - date Hg will be available for write access (it should be frozen for
> a while, to give the folks doing the conversion a chance to make sure
> buildbot is back up and run, commit emails are working properly, etc)
I would target the build slaves to the Mercurial repository already in
the testing
> Maybe I misremembered Martin's suggestion, and he was only talking about
> security releases.
Technically, I was only talking about 2.5. For each branch, the
respective release manager should make a decision. For 2.5 and 2.6,
it's been decided; Benjamin has not yet announced plans how 2.7 and 3.
> I don't understand all the worry about sys.subversion.
Really? For a security release, there should be *zero* chance that it
breaks existing applications, unless the application relies on the
security bug that has been fixed. By "zero chance", I mean absolutely
no chance, never. I'm pretty sure
> In my opinion, the question is more what was it not fixed in Python2. I
> suppose
> that the answer is something ugly like "backward compatibility" or
> "historical
> reasons" :-)
No, there was a deliberate decision to not support that, see
http://www.python.org/dev/peps/pep-0261/
There ha
> It'S rather common to confuse a transfer encoding with a storage format.
> UCS2 and UCS4 refer to code units (the storage format).
Actually, they don't. Instead, they refer to "coded character sets",
in W3C terminology: mapping of characters to natural numbers. See
http://unicode.org/faq/basic_
Am 20.11.2010 05:11, schrieb Stephen J. Turnbull:
> "Martin v. Löwis" writes:
>
> > The term "UCS-2" is a character set that can encode only encode 65536
> > characters; it thus refers to Unicode 1.1. According to the Unicode
> > Consortium's
> > I disagree. Python does "conform" to "UTF-16"
>
> I'm sure the codecs do. But the Unicode standard doesn't care about
> the parts of the process, it cares about what it does as a whole.
Chapter and verse?
> Python's internal coding does not conform to UTF-16, and that internal
> coding can
> Unicode 5.0, Chapter 3, verse C9:
>
> When a process generates a code unit sequence which purports to be
> in a Unicode character encoding form, it shall not emit ill-formed
> code sequences.
> > > A Unicode-conforming Python implementation would error at the
> > > chr() call, or
Am 22.11.2010 11:47, schrieb Stephen J. Turnbull:
> "Martin v. Löwis" writes:
>
> > More interestingly (and to the subject) is chr: how did you arrive
> > at C9 banning Python3's definition of chr? This chr function puts
> > the code sequence into well-f
Am 22.11.2010 11:48, schrieb Stephen J. Turnbull:
> Raymond Hettinger writes:
>
> > Neither UTF-16 nor UCS-2 is exactly correct anyway.
>
>>From a standards lawyer point of view, UCS-2 is exactly correct, as
> far as I can tell upon rereading ISO 10646-1, especially Annexes H
> ("retransmitting
> Solaris overcomes most of the issue having separate library searchpath
> in 32 and 64 bits (via the "crle" command). But in some cases python try
> to find some library in "/usr/local/lib", and my point is that it should
> search TOO inside "/usr/local/lib/64".
I don't think this will work. If t
> I actually agree. I am not sure yet, but I am thinking that adding a
> "--build-64" parameter to "configure" could be an option under Solaris.
> Most OSs (let say, Linux) force you to choose 32/64 bits at install
> time
Actually, that's not at all the case. Most systems these days support
32-bit
Am 22.11.2010 23:51, schrieb Éric Araujo:
> Hi,
>
> I think this bug is related: http://bugs.python.org/issue1294959
> “Problems with /usr/lib64 builds.”
Perhaps more closely related:
http://bugs.python.org/issue847812
http://bugs.python.org/issue1733484
http://bugs.python.org/issue1676121
http:
Am 23.11.2010 00:41, schrieb Jesus Cea:
> On 22/11/10 23:05, "Martin v. Löwis" wrote:
>>> PS: Martin, is there any reason to restrict the solaris 10 buildslaves
>>> to 32 bits, beside the said problems?.
>
>> I don't see that as a restriction. I have
Am 23.11.2010 00:48, schrieb Jesus Cea:
> I think this is probably trivial, but is there any foolproof way to
> detect 64 bit builds in python, beside "sys.maxint"?.
The canonical way is to use platform.architecture().
> And any macro useable for conditional compilation in C?.
You need to be mor
> But if we say the Python can be compiled as 64 bits under Solaris, would
> be nice if that was actually true. Now that we have a buildbot (under
> OpenIndiana) to test, it is doable.
But it is true, and always has been true. The lib/64 issue did not
prevent one building Python on Solaris/SPARC64
Am 23.11.2010 11:55, schrieb Amaury Forgeot d'Arc:
> Hi,
>
> 2010/11/23 Glenn Linderman :
>> File "C:\Python32\lib\random.py", line 108, in seed
>> a = int.from_bytes(_urandom(32), 'big')
>> WindowsError: [Error -2146893818] Invalid Signature
>
> In the subprocess documentation http://docs.
> I have read some about side-by-side assemblies but had considered them a
> good reason to stick with the outdated M$VC 6.0 compiler, which doesn't
> seem to need to create them, and their myriad requirements, which seem
> far from necessary for simply compiling a program. I was disappointed
> to
> So I presume it did the same with IOBinding.py.
No. This file contains only ASCII characters, so notepad has decided
to not add the BOM.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-d
> Is it possible a conversion from bytes (ANSI) to unicode fails on
> windows?
It should fail sometimes, right? Not for windows-1252, but certainly
for shift-jis (you know better than me). It seems that whether
MultiByteToWideChar will fail depends on whether MB_ERR_INVALID_CHARS
is given or not.
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
> 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
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
>> 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 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
&
>>> 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
> 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
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@
> 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
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 di
> 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 l
> 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
> 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 n
>> - 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
spe
> 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
> 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 affec
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...@8
Am 29.11.2010 19:33, schrieb Antoine Pitrou:
> On Mon, 29 Nov 2010 08:22:46 +0100
> "Martin v. Löwis" 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 t
> - 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, su
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?
>
Am 30.11.2010 09:15, schrieb Hagen Fürstenau:
>>> During PEP 3003 discussion, it was suggested to handle it on a case by
>>> case basis, but I don't see discussion of the upgrade to 6.0.0 in PEP
>>> 3003.
>>
>> It's covered by "As the standard library is not directly tied to the
>> language definit
> Would moving this functionality to the locale module make the issues any
> easier to fix?
You could delegate it to the C library, so: yes.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
Am 30.11.2010 20:23, schrieb Antoine Pitrou:
> Le mardi 30 novembre 2010 à 20:16 +0100, "Martin v. Löwis" a écrit :
>>> Would moving this functionality to the locale module make the issues any
>>> easier to fix?
>>
>> You could delegate it to the C libr
> Because we all know how locale is a pile of cr*p, both in specification
> and in implementations. Our unit tests for it are a clear proof of that.
I wouldn't use expletives, but rather claim that the locale module is
highly platform-dependent.
> Actually, I remember you saying that locale shoul
Am 30.11.2010 21:24, schrieb Ben Finney:
> haiyang kang writes:
>
>> I think it is a little ugly to have code like this: num =
>> float("一.一"), expected result is: num = 1.1
>
> That's a straw man, though. The string need not be a literal in the
> program; it can be input to the program.
>
>
Am 30.11.2010 23:43, schrieb Terry Reedy:
> On 11/30/2010 3:23 AM, Stephen J. Turnbull wrote:
>
>> I see no reason not to make a similar promise for numeric literals. I
>> see no good reason to allow compatibility full-width Japanese "ASCII"
>> numerals or Arabic cursive numerals in "for i in ran
>> And here, my observation stands: if they wanted to, they currently
>> couldn't - at least not for real numbers (and also not for integers
>> if they want to use grouping). So the presumed application of this
>> feature doesn't actually work, despite the presence of the feature it
>> was supposed
>> I think the OP (haiyang kang) already indicated that he finds it quite
>> unlikely that anybody would possibly want to enter that.
>
> Who's talking about *entering* it into the program at a keyboard
> directly, though? Input to a program can come from all kinds of crazy
> sources. Just because
> 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.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
ht
Am 01.12.2010 20:02, schrieb Brian Curtin:
> On Wed, Dec 1, 2010 at 12:51, Prashant Kumar
> mailto:contactprashan...@gmail.com>> wrote:
>
> Hello everyone. My name is Prashant. I and my friend Zubin recently
> ported 'Configobj'. It would be great if somebody can suggest about
> any ut
Am 02.12.2010 03:01, schrieb Ben Finney:
> "Stephen J. Turnbull" 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 left is
1401 - 1500 of 5277 matches
Mail list logo
