Re: [Python-Dev] Commit access request
Benjamin Peterson schrieb: > Hi Python devs, > I have been contributing to since December. (See me first issue on the > tracker, #1828; it was a major learning experience.) :P In that time, I > have contributed many patches and actively participated on this list. > This will enable me to help triage bugs on the tracker, something I've > been wanting to help with. I'm +1 to Benjamin getting commit privileges, letting commits sign off by a senior developer. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: from __future__ import unicode_string_literals
On 2008-03-24 09:22, Lennart Regebro wrote: > I think 2to3 is a procedure that will work well for library type > projects with a reasonably small set of developers that make regular > releases. There you can release both a python 2 and a python 3 version > of the module, for example. > ... > So, in short: Large projects with interconnected modules where the > developers and users of module are the same people will have big > difficulties with the 2to3 approach and would be the people who are > most likely to not be able to in practice go forward to Python 3 > unless they have some sort of smooth path forward. I don't think there's a lot to worry about: Companies using Python for applications typically have a completely different life-cycle of releases and applications compared to the Python release schedule, i.e. they often still run Python 2.3 or 2.4 and wait for major releases to settle before deciding to port to them. Every now and then, they make the decision to port to the next release (for the next version of their software) and this change is then managed accordingly - sometimes skipping a complete major release of Python. In such projects, 2to3 will get applied to the sources once and then all development continues on the Python 3.0 version of the code. In reality, I don't think that 2to3 will get used for continuous porting between a 2.x code base and a 3.0 one all that much. The transition from 2.x to 3.0 will happen during a longer period of time (probably a few years) and depend a lot on the release cycle of the applications using Python, whether or not the 3.0 version provides better features, more performance, etc. and whether the 2.x branches of Python and the used 3rd party modules are still supported or not. New applications will likely choose 3.0 right away - provided that the needed 3rd party modules are available and stable enough. In summary: 2to3 is a very useful tool to have. Whether or not it is used for continuous porting between the two worlds is really secondary. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 25 2008) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: from __future__ import unicode_string_literals
Lennart Regebro wrote:
> On Mon, Mar 24, 2008 at 12:14 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>>> You are still only seeing this as a case of libraries with a small
>> > number of people developing them and making regular well defined
>> > releases. That is not how the world I am talking about looks.
>>
>> Can you give me examples of such software?
>
> I'll repeat the link where I explained my point on this:
> http://regebro.wordpress.com/2008/03/22/why-python-26-and-30-compatibility-would-be-a-very-good-thing/
Yet, there you merely claim that such software exists ("within larger
organizations", and "within large communities like Zope and Plone"),
without giving specific examples.
This is not very convincing.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k and asyncore/asynchat
On Mon, Mar 24, 2008 at 03:51:56PM -0700, Josiah Carlson wrote: > reasonable question; 2.6 alpha 1 has been released. It's a question > as to whether someone with commit access can or will commit the patch > as posted, run the tests to verify that they aren't broken, and > perhaps actually look at the code to verify that we (Giampaolo and I) > aren't insane. Mind you, I've been using very similar variants of I think we should just give you commit access so that you can commit changes to asyncore/asynchat yourself; it doesn't seem as if any of the committers use asyncore enough to check patches for it. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: from __future__ import unicode_string_literals
On Mon, Mar 24, 2008 at 10:23 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Yet, there you merely claim that such software exists ("within larger
> organizations", and "within large communities like Zope and Plone"),
> without giving specific examples.
No I don't. Here is what I said:
"In many other cases, this is not how code is developed. Both within
larger organisations and within large communities like Zope and
Plone".
I don't think chewing through this issue once more is meaningful, so
I'll stop now.
--
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Decimal(unicode)
Hello. In Python 2.5.1 the code import decimal for d in '123', u'123': x = decimal.Decimal(d) print type(x.to_eng_string()) prints In 2.5.2 it prints Why the change? Is it a bug or a feature? Shouldn't .to_eng_string() always return a str? Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python source code on Bazaar vcs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 24, 2008, at 11:06 PM, [EMAIL PROTECTED] wrote: >Barry> All the gory details are documented here: > >Barry> http://www.python.org/dev/bazaar > > Thanks. I checked out, made a branch named test3, changed > Makefile.pre.in > to have a test3 target, checked it in, then tried to push it: > >% pwd >/Users/skip/src/python-bzr/test3 >% bzr push bzr+ssh://[EMAIL PROTECTED]/python/users/skip/ > test3 >bzr: ERROR: Parent directory of bzr+ssh:// > [EMAIL PROTECTED]/python/users/skip/test3 does not exist. >You may supply --create-prefix to create all leading parent > directories. > > Did I misread the directions or do I really need the --create-prefix > arg? You do, the first time you push a user branch because users/skip doesn't exist yet. It's mentioned in the docs, but it's pretty easy to overlook ;). - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR+kNxXEjvBPtnXfVAQJMWQP8DJrB6QbXt7O/lT2Y/CzxpuEqa09rOSGq QxE6RDro/k4dvuwRGh3WKjo+AwKcSSTsUAp48o3O1fM7X3u54JxhtbwoEeZj7xnv 9Nw6ZCpN+DDY83QAtNjkWtSkNfRaL3K1Y4gZsnsxsIDGs3y0HV5a2n8vZh18b+gV xfJzxu+hb/o= =BsR5 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal(unicode)
On Tue, Mar 25, 2008 at 9:46 AM, Oleg Broytmann <[EMAIL PROTECTED]> wrote: >In 2.5.2 it prints > > > > >Why the change? Is it a bug or a feature? Shouldn't .to_eng_string() > always return a str? I'd call this a bug. The change is an accident, a side-effect of the fact that in 2.5.1 the coefficient (mantissa) of a Decimal was stored as a tuple, and in 2.5.2 it's stored as a string (which greatly improves efficiency). Clearly in 2.5.2 the mantissa is being stored as a unicode instance in the second case; it should be explicitly coerced to str in Decimal.__new__. If others agree that it's a bug, I'll fix it. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal(unicode)
On Tue, Mar 25, 2008 at 9:46 AM, Oleg Broytmann <[EMAIL PROTECTED]> wrote: >In 2.5.2 it prints > > > > >Why the change? Is it a bug or a feature? Shouldn't .to_eng_string() > always return a str? I'd call this a bug. The change is an accident, a side-effect of the fact that in 2.5.1 the coefficient (mantissa) of a Decimal was stored as a tuple, and in 2.5.2 it's stored as a string (which greatly improves efficiency). Clearly in 2.5.2 the mantissa is being stored as a unicode instance in the second case; it should be explicitly coerced to str in Decimal.__new__. If others agree that it's a bug, I'll fix it. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal(unicode)
2008/3/25, Mark Dickinson <[EMAIL PROTECTED]>: > > I'd call this a bug. The change is an accident, a side-effect of the fact > that in 2.5.1 the coefficient (mantissa) of a Decimal was stored as a > tuple, and in 2.5.2 it's stored as a string (which greatly improves > efficiency). > Clearly in 2.5.2 the mantissa is being stored as a unicode instance in the > second case; it should be explicitly coerced to str in Decimal.__new__. > > If others agree that it's a bug, I'll fix it. > +1 -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal(unicode)
Mark Dickinson wrote:
> On Tue, Mar 25, 2008 at 9:46 AM, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
>>In 2.5.2 it prints
>>
>>
>>
>>
>>Why the change? Is it a bug or a feature? Shouldn't .to_eng_string()
>> always return a str?
>
> I'd call this a bug. The change is an accident, a side-effect of the fact
> that in 2.5.1 the coefficient (mantissa) of a Decimal was stored as a
> tuple, and in 2.5.2 it's stored as a string (which greatly improves
> efficiency).
> Clearly in 2.5.2 the mantissa is being stored as a unicode instance in the
> second case; it should be explicitly coerced to str in Decimal.__new__.
>
> If others agree that it's a bug, I'll fix it.
I thought that might be what happened, but I couldn't remember if that
optimisation was a 2.6 only change or not (I suspect it was included in
2.5 as a prereq to the spec compliance updates).
Anyway, +1 on coercing the mantissa to a str() instance in 2.5.
This does raise an interesting point though - currently Decimal in Py3k
is storing the mantissa as a Unicode instance instead of a bytes
instance. The performance implications of that are horrendous since
PyLong_FromUnicode does a malloc, encodes the string into the malloced
buffer, then invokes PyLong_FromString on the result.
To fix this, decimal probably needs to grow something like the following
near the top of the module:
try:
_bytes = bytes
except NameError: # 2.5 or earlier
_bytes = str
and then use _bytes instead of str as appropriate throughout the rest of
the module.
The following is also a problem in Py3k:
>>> from decimal import Decimal as d
>>> d(1)
Decimal('1')
>>> d('1')
Decimal('1')
>>> d(b'1')
Traceback (most recent call last):
File "", line 1, in
File "/home/ncoghlan/devel/py3k/Lib/decimal.py", line 659, in __new__
raise TypeError("Cannot convert %r to Decimal" % value)
TypeError: Cannot convert b'1' to Decimal
The isinstance(value, str) check in Py3k is too restrictive - it needs
to accept bytes instances as well.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal(unicode)
On Tue, Mar 25, 2008 at 10:47:42AM -0400, Mark Dickinson wrote: > On Tue, Mar 25, 2008 at 9:46 AM, Oleg Broytmann <[EMAIL PROTECTED]> wrote: > >In 2.5.2 it prints > > > > > > > > > >Why the change? Is it a bug or a feature? Shouldn't .to_eng_string() > > always return a str? > > I'd call this a bug. The change is an accident, a side-effect of the fact > that in 2.5.1 the coefficient (mantissa) of a Decimal was stored as a > tuple, and in 2.5.2 it's stored as a string (which greatly improves > efficiency). > Clearly in 2.5.2 the mantissa is being stored as a unicode instance in the > second case; it should be explicitly coerced to str in Decimal.__new__. > > If others agree that it's a bug, I'll fix it. http://bugs.python.org/issue2482 Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal(unicode)
On Tue, Mar 25, 2008 at 11:29 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > I thought that might be what happened, but I couldn't remember if that > optimisation was a 2.6 only change or not (I suspect it was included in > 2.5 as a prereq to the spec compliance updates). > Exactly. > Anyway, +1 on coercing the mantissa to a str() instance in 2.5. > > This does raise an interesting point though - currently Decimal in Py3k > is storing the mantissa as a Unicode instance instead of a bytes > instance. The performance implications of that are horrendous since > PyLong_FromUnicode does a malloc, encodes the string into the malloced > buffer, then invokes PyLong_FromString on the result. > Urk! Yes, this definitely needs to be looked at. > The following is also a problem in Py3k: > [...] > > The isinstance(value, str) check in Py3k is too restrictive - it needs > to accept bytes instances as well. > I don't understand this. Why does Decimal.__new__ need to accept bytes instances? Isn't it just supposed to be creating a Decimal from a string? Or is the idea that it should accept ASCII strings that are masquerading as bytes instances, for reasons of convenience/efficiency/something else? Unicode/bytes/str and encoding issues frighten me much more than floating-point arithmetic ever did, so I expect I'm missing many things here. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal(unicode)
2008/3/25, Nick Coghlan <[EMAIL PROTECTED]>: > > Anyway, +1 on coercing the mantissa to a str() instance in 2.5. > I don't know about 2.5, I'm sure about 2.6. > To fix this, decimal probably needs to grow something like the following > near the top of the module: > > try: >_bytes = bytes > except NameError: # 2.5 or earlier >_bytes = str > > and then use _bytes instead of str as appropriate throughout the rest of > the module. +1, I updated the bug created by Oleg. > The isinstance(value, str) check in Py3k is too restrictive - it needs > to accept bytes instances as well. Why? The number in a string should be just strings, IMHO, not bytes... do you have a case of use for this? Thanks! -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal(unicode)
On Tue, Mar 25, 2008 at 11:29 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > The isinstance(value, str) check in Py3k is too restrictive - it needs > to accept bytes instances as well. > Hmm. There's not a lot of consistency here: >>> int(b'1') 1 >>> float(b'1') 1.0 >>> complex(b'1') Traceback (most recent call last): File "", line 1, in TypeError: complex() argument must be a string or a number >>> from fractions import Fraction >>> Fraction(b'1') Traceback (most recent call last): File "", line 1, in File "/Users/dickinsm/python_source/py3k/Lib/fractions.py", line 98, in __new__ numerator = numerator.__index__() AttributeError: 'bytes' object has no attribute '__index__' So int and float accepts bytes, while complex, Decimal and Fraction do not... Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal(unicode)
2008/3/25, Mark Dickinson <[EMAIL PROTECTED]>: > So int and float accepts bytes, while complex, Decimal and Fraction do > not... I'm -1 to accept bytes as input for Decimal, I don't see a case of use, and I think that conceptually there's no reason to do it. Of course, I can be wrong, ;) Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal(unicode)
On Tue, Mar 25, 2008 at 11:57 AM, Facundo Batista <[EMAIL PROTECTED]> wrote: > 2008/3/25, Mark Dickinson <[EMAIL PROTECTED]>: > > > So int and float accepts bytes, while complex, Decimal and Fraction do > > not... > > I'm -1 to accept bytes as input for Decimal, I don't see a case of > use, and I think that conceptually there's no reason to do it. > I've opened http://bugs.python.org/issue2483 to keep track of this. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal(unicode)
Facundo Batista wrote: > 2008/3/25, Mark Dickinson <[EMAIL PROTECTED]>: > >> So int and float accepts bytes, while complex, Decimal and Fraction do >> not... > > I'm -1 to accept bytes as input for Decimal, I don't see a case of > use, and I think that conceptually there's no reason to do it. > > Of course, I can be wrong, ;) I was thinking converting directly from bytes would be significantly quicker than going through Unicode (e.g. for numbers read from a file), but that may not actually be the case (it'll definitely be faster because there is less data copying and movement involved, but the speed difference may be less dramatic than I first thought). So while the internal storage of the mantissa definitely needs to be changed to a bytes object in order to retain Mark's hard-won performance improvements, the case of whether or not to accept bytes is far less clear. The way I see it either complex, Decimal and Fraction all need to be updated to accept bytes objects, or else int and float need to be updated to reject them. It *definitely* needs to be possible to convert bytes objects to integers as if they were ASCII strings - otherwise a lot of wire protocol processing would become a nightmare. Indeed, the proposed change to Decimal to have it store the mantissa as a bytes object in Py3k assumes that it will still be possible to convert that value directly to a long object. Since we have some strong use cases at least for the bytes->int case, consistency then suggests that the other numeric types should all accept bytes as well (interpreting them as ASCII encoded strings). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal(unicode)
On Tue, Mar 25, 2008 at 9:43 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: ... > Since we have some strong use cases at least for the bytes->int case, > consistency then suggests that the other numeric types should all accept > bytes as well (interpreting them as ASCII encoded strings). +1 -- it seems very practical as well as consistent, and I see no downsides. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Commit access request
Georg Brandl schrieb: > Benjamin Peterson schrieb: >> Hi Python devs, >> I have been contributing to since December. (See me first issue on the >> tracker, #1828; it was a major learning experience.) :P In that time, I >> have contributed many patches and actively participated on this list. >> This will enable me to help triage bugs on the tracker, something I've >> been wanting to help with. > > I'm +1 to Benjamin getting commit privileges, letting commits sign off > by a senior developer. Since there are no objections, I've now added Benjamin's key, under that condition. Welcome on board, Benjamin! :) Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Two questions about jump opcodes
This across the board speedup of the python byte code looks promising! I'm not familiar enough with that part of the code to review it but here's a big +1 to make sure someone else takes a look. On Sat, Mar 22, 2008 at 4:07 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote: > > Wow, thanks to both of you (Phillip & Skip) for the fast answers. > Just in case anyone has time to spare, I have more pesky questions (and a > working patch :-)) in the aforementioned bug entry > (http://bugs.python.org/issue2459). > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/greg%40krypto.org > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python source code on Bazaar vcs
>> Did I misread the directions or do I really need the --create-prefix >> arg? Barry> You do, the first time you push a user branch because users/skip Barry> doesn't exist yet. It's mentioned in the docs, but it's pretty Barry> easy to overlook ;). Well, I noticed the mention in .../dev/bazaar, where it reads, "the first time you do this, you might need to add --create-prefix". Perhaps that should read "... you will need to ...". It pushed fine with --create-prefix. Thanks, Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal(unicode)
"Mark Dickinson" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | On Tue, Mar 25, 2008 at 11:29 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: | | > The isinstance(value, str) check in Py3k is too restrictive - it needs | > to accept bytes instances as well. | > | | Hmm. There's not a lot of consistency here: | | >>> int(b'1') | 1 | >>> float(b'1') | 1.0 | >>> complex(b'1') | Traceback (most recent call last): | File "", line 1, in | TypeError: complex() argument must be a string or a number | >>> from fractions import Fraction | >>> Fraction(b'1') | Traceback (most recent call last): | File "", line 1, in | File "/Users/dickinsm/python_source/py3k/Lib/fractions.py", line 98, in | __new__ |numerator = numerator.__index__() | AttributeError: 'bytes' object has no attribute '__index__' | | So int and float accepts bytes, while complex, Decimal and Fraction do | not... The purpose of type constructors is to construct instances from reasonable inputs. I think all number constructors should accept bytes and so the latter three should be changed. tjr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: from __future__ import unicode_string_literals
Follow up: Neal and I've created a working patch, http://bugs.python.org/issue2477 We had to modify the parser API and add two functions. The two new functions are slightly modified versions of existing functions. We needed the flag argument to be an input/output variable (pointer) instead of a input only variable. The rest of the code is straight forward. I like to get the review of another developer before I commit the code. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Commit access request
On Tue, Mar 25, 2008 at 12:40 PM, Georg Brandl <[EMAIL PROTECTED]> wrote: > Georg Brandl schrieb: > > Benjamin Peterson schrieb: > >> Hi Python devs, > >> I have been contributing to since December. (See me first issue on the > >> tracker, #1828; it was a major learning experience.) :P In that time, I > >> have contributed many patches and actively participated on this list. > >> This will enable me to help triage bugs on the tracker, something I've > >> been wanting to help with. > > > > I'm +1 to Benjamin getting commit privileges, letting commits sign off > > by a senior developer. > > Since there are no objections, I've now added Benjamin's key, under that > condition. Thanks! > > > Welcome on board, Benjamin! :) Glad to help! > > > Georg > > > -- > Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. > Four shall be the number of spaces thou shalt indent, and the number of > thy > indenting shall be four. Eight shalt thou not indent, nor either indent > thou > two, excepting that thou then proceed to four. Tabs are right out. > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com > -- Cheers, Benjamin Peterson ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal(unicode)
> I'd call this a bug. The change is an accident, a side-effect of the fact > that in 2.5.1 the coefficient (mantissa) of a Decimal was stored as a > tuple, and in 2.5.2 it's stored as a string (which greatly improves > efficiency). > Clearly in 2.5.2 the mantissa is being stored as a unicode instance in the > second case; it should be explicitly coerced to str in Decimal.__new__. > > If others agree that it's a bug, I'll fix it. If people agree it's a bug, please do fix it. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal(unicode)
Martin v. Löwis wrote: >> I'd call this a bug. The change is an accident, a side-effect of the fact >> that in 2.5.1 the coefficient (mantissa) of a Decimal was stored as a >> tuple, and in 2.5.2 it's stored as a string (which greatly improves >> efficiency). >> Clearly in 2.5.2 the mantissa is being stored as a unicode instance in the >> second case; it should be explicitly coerced to str in Decimal.__new__. >> >> If others agree that it's a bug, I'll fix it. > > If people agree it's a bug, please do fix it. It looks like a bug to me. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How we can get rid of eggs for 2.6 and beyond
ajaksu wrote: > While Linux and OS X both view Python as essentially a first-class > development platform-i.e., as something that shrink-wrap applications > can be built on-Windows does not. Even on MacOSX and Linux, you can't rely on the system coming with the particular version of Python you want to use pre-installed. So unless you target a very old version of Python, you have to bundle anyway if you don't want users to have to download and install a bunch of dependencies. If the situation is any better on Linux, it's probably because Linux users tend to be more willing and/or able to track down and install dependencies along with an app. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal(unicode)
Nick Coghlan wrote: > Since we have some strong use cases at least for the bytes->int case, > consistency then suggests that the other numeric types should all accept > bytes as well (interpreting them as ASCII encoded strings). How far should this go? Is conversion to numbers really so special, or should bytes be acceptable in any context requiring a string, with an implicit encoding of ascii? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backport of bytearray type and io module
Christian Heimes schrieb: > Hello! > > I've successfully back ported the bytearray type and the io module from > 3.0 to 2.6. The code is available in the branch trunk-bytearray [1]. I'm > down to four failing byte tests and one failing io test. The failing > byte tests are all related to pickling and subclassing. > > I like to get the remaining tests fixed for the upcoming release in a > week. Please checkout the branch and help me figure out the remaining > issues. Follow up: All failing bytearray tests were caused by subclasses of bytearray. I've removed the Py_TPFLAGS_BASETYPE flag for now. Are you fine with the inclusion of bytearray although it can't be subclassed? I'm going to fix the last io bug now. I like to merge the backport of bytearray and io before the next alpha gets shipped out. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backport of bytearray type and io module
I'm okay with bytearray not being subclassable in 2.6 as a temporary measure. I wouldn't want that to leak into 3.0 though, and I'd rather have it subclassable in 2.6 as well. I wonder why it doesn't work in 2.6 but does work in 3.0? On Tue, Mar 25, 2008 at 5:05 PM, Christian Heimes <[EMAIL PROTECTED]> wrote: > Christian Heimes schrieb: > > > Hello! > > > > I've successfully back ported the bytearray type and the io module from > > 3.0 to 2.6. The code is available in the branch trunk-bytearray [1]. I'm > > down to four failing byte tests and one failing io test. The failing > > byte tests are all related to pickling and subclassing. > > > > I like to get the remaining tests fixed for the upcoming release in a > > week. Please checkout the branch and help me figure out the remaining > > issues. > > Follow up: > > All failing bytearray tests were caused by subclasses of bytearray. I've > removed the Py_TPFLAGS_BASETYPE flag for now. Are you fine with the > inclusion of bytearray although it can't be subclassed? > > I'm going to fix the last io bug now. I like to merge the backport of > bytearray and io before the next alpha gets shipped out. > > Christian > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backport of bytearray type and io module
Guido van Rossum schrieb: > I'm okay with bytearray not being subclassable in 2.6 as a temporary > measure. I wouldn't want that to leak into 3.0 though, and I'd rather > have it subclassable in 2.6 as well. I wonder why it doesn't work in > 2.6 but does work in 3.0? It *seems* like the comparison ops don't work correctly for subclasses. In general subclassing works but comparison of subclasses result in wrong results. It's probably easy to fix but I haven't figured it out yet. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal(unicode)
Terry Reedy wrote: > The purpose of type constructors is to construct instances from reasonable > inputs. I think all number constructors should accept bytes What should bytes as input to a number constructor mean, though? People seem to be assuming it should be interpreted as ASCII-encoded characters. But an equally plausible interpretation might be that it's some binary representation of a number. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal(unicode)
Greg Ewing wrote: > Terry Reedy wrote: >> The purpose of type constructors is to construct instances from reasonable >> inputs. I think all number constructors should accept bytes > > What should bytes as input to a number constructor > mean, though? > > People seem to be assuming it should be interpreted > as ASCII-encoded characters. > > But an equally plausible interpretation might be > that it's some binary representation of a number. The difference is that there are some hardware control protocols which it makes sense to treat as sequences of bytes, which also contain numbers as ASCII digits which need to be processed. It's also the case that the permitted characters when passing a *string* to a numeric constructor are themselves an ASCII subset. For binary representations, we already have the struct module to handle the parsing, but for byte sequences with embedded ASCII digits it's reasonably common practice to use strings along with the respective type constructors. However, Mark found another problem when he attempted to speed up the Py3k version of decimal by storing the mantissa as a bytes object instead of a unicode string: there is currently no efficient way to serialise a number into a byte sequence. So storing the mantissa as a bytes object is actually currently slower than storing it as a string, as you have to convert the number to a string before you can store it in a bytes object. That still leaves us with the problem that decimal is about 25% slower in 3.0 than it is in 2.6, due to the fact that the unicode->int conversion is much slower than the corresponding 2.x str->int conversion. Ugly problem :P Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal(unicode)
2008/3/25, Alex Martelli <[EMAIL PROTECTED]>:
> > Since we have some strong use cases at least for the bytes->int case,
> > consistency then suggests that the other numeric types should all accept
> > bytes as well (interpreting them as ASCII encoded strings).
>
> +1 -- it seems very practical as well as consistent, and I see no downsides.
Mmm... Py3k-ish speaking
"2.13" is an unicode string that holds four digits, two point one
three, which if converted to Decimal, gives me, well, Decimal("2.13").
b"2.13", as it's not a string of digits anymore, but a stream of 4
bytes, that represents the binary number 0x322e3133...
So, what I find difficult to know is how can you undoubtly express a
collection of digits (inherent to strings) through bytes (without
mixing pre-3k concepts).
Regards,
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k and asyncore/asynchat
On Thu, Feb 14, 2008 at 10:09 AM, Giampaolo Rodola' <[EMAIL PROTECTED]> wrote: > On 14 Feb, 16:36, "Giampaolo Rodola'" <[EMAIL PROTECTED]> wrote: > > Ok, I'll try to take a look at all asyncore/chat reports and try to > > summarize them by splitting patches which solve bugs and patches which > > add enhancements or functionalities. > > === Patches for existing issues === > > - 1736190 which includes fixes for the following issues among other > improvements: > - 1063924 (asyncore should handle ECONNRESET in send()) > - 1736101 (asyncore should handle ECONNABORTED in recv()) > - 760475 (handle_error() should call handle_close() instead of > close()) > - 1740572 (refill_buffer() should call handle_close() rather than > close()) > - 777588 (wrong "connection refused" behavior on Windows) > - 889153 (wrong connect() behavior) > - 953599 (asyncore misses socket closes when poll is used) > - 1025525 (asyncore.file_dispatcher should not take fd as argument) > > - 1519 (async_chat.__init__() and asyncore.dispatcher.__init__ > parameters inconsistency) > - 1541 (Bad OOB data management when using asyncore with > select.poll()) > - 2073 (asynchat push always sends 512 bytes (ignoring > ac_out_buffer_size)) > > > === Open issues with no patches (need review) === > > - 658749 (asyncore connect() and winsock errors) > - 1161031 (neverending warnings from asyncore) > > > === Enhancements & new features === > > - 1641 (add delayed calls feature) > - 1563 (conversion to py3k and some other changes) That's a lot of patches. My immediate concern is that test_asynchat is very flaky and fails often. Sometimes it causes other tests to fail. Is there a patch that addresses this? If you need examples, just look through the buildbot mails that mention test_asynchat in: http://mail.python.org/pipermail/python-checkins/ Some platforms have more problems than others, but almost all platforms have failed test_asynchat at one point or another. Please break up the patches into 2 sets and prioritize the patches with the set. Set #1: Patches that have a test and doc updates if required Set #2: Patches that don't have a test or doc updates as required For the patches that fall into Set #1, list them in priority order. Top priority would be a problem that fixes failures seen in the buildbots. Next priority would go to the patches that solve more serious problems. Post the results here. I will try to look at them. For every patch you list, make sure that it conforms to the proper style (e.g, PEP 8) and is essentially perfect and ready for inclusion. This means that there is a single file to download that contains all the modifications. The changes are appropriately commented, lines are less than 80 characters, etc. One of the modifications should be an entry in Misc/NEWS. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal(unicode)
I thought Decimal was going to be replaced by a C implementation soon anyway. If so, is it worth going to much trouble over this? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal(unicode)
> For binary representations, we already have the struct module to handle
> the parsing, but for byte sequences with embedded ASCII digits it's
> reasonably common practice to use strings along with the respective type
> constructors.
Sure, but why can't you write
foo = int(bar[start:stop].decode("ascii"))
then? Explicit is better than implicit.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] the release gods are angry at python
The next releases of 2.6/3.0 are planned for April 2, just over a week from now. There is much work that needs to be done. The buildbots are in a pretty sad state and the gods are seeing too much red. http://www.python.org/dev/buildbot/stable/ http://www.python.org/dev/buildbot/all/ See my other mail that discusses the stable buildbots. The criteria for release is that all the stable buildbots are passing all the tests. So we really gotta get these green before Barry notices. You don't want to see Barry angry. You wouldn't like him when he's angry. I propose a code chill for new features. Changes to doc and tests can continue as usual. However, only submit a new feature *after* you fix a broken test first. If we have to get draconian, we can start breaking fingers when you break a test just like we do at work. :-) Specifically tests that need some TLC are: * test_winsound - http://www.python.org/dev/buildbot/stable/x86%20XP-3%20trunk/builds/1166/step-test/0 * test_threading - test_no_refcycle_through_target - http://www.python.org/dev/buildbot/stable/x86%20XP-3%20trunk/builds/1166/step-test/0 * test_socket deadlocks and times out - http://www.python.org/dev/buildbot/stable/x86%20W2k8%20trunk/builds/210/step-test/0 * test_ssl deadlocks and times out - http://www.python.org/dev/buildbot/all/S-390%20Debian%20trunk/builds/255/step-test/0 * test_xmlrpc transient socket errors - http://www.python.org/dev/buildbot/stable/g4%20osx.4%20trunk/builds/3101/step-test/0 * test_mailbox - http://www.python.org/dev/buildbot/stable/x86%20XP-3%203.0/builds/723/step-test/0 * test_asynchat - http://www.python.org/dev/buildbot/all/alpha%20Tru64%205.1%20trunk/builds/2756/step-test/0 Hopefully test_timeout is fixed, but that might be flaky too. There have been other tests that have also been flaky like test_asynchat, test_smtplib, test_ssl, test_urllib2net, test_urllibnet, test_xmlrpc_net and some of the tests that use networking. These all need to be fixed so the tests are 100% reliable and only fail when there is a real error. There are currently no release blocker issues: http://bugs.python.org/issue?%40columns=title&%40columns=id&%40sort=activity&priority=1&%40group=priority&status=1&%40action=search There are 48 critical issues: http://bugs.python.org/issue?%40columns=title&%40columns=id&%40sort=activity&priority=2&%40group=priority&status=1&%40action=search If you believe any issue should block the release, set the priority to release blocker and assign it to me (nnorwitz). Many of the critical issues are those that require 2to3 fixers. These can be checked in as they are written. Be sure to test them thoroughly and try to think of all the conditions that could possibly cause the fixer to fail or do the wrong thing. Right now, I don't know of any reason to hold up the release other than the failing tests. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] stable buildbots
We need to get the tests for Python to be more stable so we can push out solid releases. In order to achieve this result, we need tests that are *100% reliable* and fail _only when there is a problem with Python_. While we aren't nearly as close to that goal as we need to be, we have to work towards it. The buildbots that have been more reliable are separated onto their own page: http://www.python.org/dev/buildbot/stable/ This is the page that should be tracked by most people. This is the page we will use to determine if Python is ready for release. All green means the release is ready to ship. This page should *always* show all green. Any change that causes any buildbot to fail, should be immediately reverted. When you commit code, make sure to refresh the stable buildbot page to ensure you haven't broken anything. The stable buildbots need to represent all major platforms, at least Windows, Mac OSX, and Linux. All of those are currently represented on the page along with several others. Unfortunately some of the tests, particularly on Windows, are not passing. We need to get these in better shape. Please help out. See my other mail for details or use the link above to find the current set of problems. As we fix more tests and more platforms become stable, I will add them to the stable page. This requires restarting the server, so I plan to do this during quiet times when all the buildbot slaves are idle. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal(unicode)
Greg Ewing wrote: > I thought Decimal was going to be replaced by a C > implementation soon anyway. If so, is it worth going > to much trouble over this? > I believe that was found to be more trouble than it was worth. So the optimisations focused on various ways of making the Python implementation more efficient. One of those ways was to store the mantissa as a string in order to gain the benefit of the fast str->int and int->str conversions. The 3.0 version no longer has that benefit, and it shows. It looks like it may be necessary to switch to a custom object for the mantissa storage in order to get those fast conversions back. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
