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 tri
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
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 talkin
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
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
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 Broytmann
-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 ha
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
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
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 i
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 sid
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 c
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
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 = byte
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 (m
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, ;)
Regard
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
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.
>
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 --
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.
>> Th
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
>> 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 menti
"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
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 i
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 tim
> 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 ins
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 b
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 wan
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,
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
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 PROTEC
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
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 cha
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
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 practica
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
> >
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:
> 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].de
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
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 towa
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
implementa
41 matches
Mail list logo
