Victor Stinner wrote:
Python contains code specific to OS/2 (eg. see Modules/posixmodule.c). I read
in Wikipedia that IBM has discontinued OS/2 support in 2005. Do we still
support OS/2 or not?
As was recently discussed, what constitutes "support" varies in perception.
Python's source contai
On Fri, Apr 16, 2010 at 2:56 PM, Raymond Hettinger
wrote:
>
>> On Fri, Apr 16, 2010 at 2:11 PM, Raymond Hettinger
>> wrote:
>>>
> Guido van Rossum, 16.04.2010 16:33:
>>
>> I am fine with
>> declaring dict({}, **{1:3}) illegal, since after all it is abuse of
>> the ** mechanism
Thanks for all the changes!
On Fri, Apr 16, 2010 at 4:00 PM, Barry Warsaw wrote:
> On Apr 15, 2010, at 08:01 PM, Guido van Rossum wrote:
>>Hm. I wish there was a way to find out whether the bytecode (or
>>whatever) actually *was* read from this file. __file__ in Python 2
>>supports this (though n
On 17/04/2010 02:43, Greg Ewing wrote:
Daniel Stutzbach wrote:
Unless you're saying you often create a dictionary, add non-string
keys, remove the non-string keys, then pass it as a **kwds? ;-)
I think the point is that it would create a very mysterious
potential failure mode. What would you
Victor> Do we still support OS/2 or not?
Yes. Andrew MacIntyre maintains the OS/2 port:
http://www.andymac.org/
He's on python-dev. You mostly see activity from him around release time.
I would contact him directly if you need some assistance from him.
Skip
__
Daniel Stutzbach wrote:
Unless you're saying you often create a dictionary, add non-string keys,
remove the non-string keys, then pass it as a **kwds? ;-)
I think the point is that it would create a very mysterious
potential failure mode. What would you make of a situation
where Python says "T
Hi,
Python contains code specific to OS/2 (eg. see Modules/posixmodule.c). I read
in Wikipedia that IBM has discontinued OS/2 support in 2005. Do we still
support OS/2 or not?
I'm asking because I'm working on a patch modifying OS2 specific code, but I'm
unable to compile nor test my changes.
On 17/04/2010 01:38, Steve Holden wrote:
Raymond Hettinger wrote:
On Apr 16, 2010, at 2:42 PM, Daniel Stutzbach wrote:
IIRC, there's a performance hack in dictobject.c that keeps track of
whether all of the keys are strings or not. The hack is designed so
that lookup operations can c
Raymond Hettinger wrote:
>
> On Apr 16, 2010, at 2:42 PM, Daniel Stutzbach wrote:
>>
>> IIRC, there's a performance hack in dictobject.c that keeps track of
>> whether all of the keys are strings or not. The hack is designed so
>> that lookup operations can call the string compare/hash functions
On Apr 16, 2010, at 11:52 AM, Guido van Rossum wrote:
>To the contrary, it was invented by Barry and ought to be added to the
>English language as a neologism.
Actually, it's an Emacs invention!
-Barry
signature.asc
Description: PGP signature
___
Pyt
On Apr 15, 2010, at 08:01 PM, Guido van Rossum wrote:
>> Byte code files contain two 32-bit numbers followed by the marshaled
>
>big-endian
Done.
>> [2]_ code object. The 32-bit numbers represent a magic number and a
>> timestamp. The magic number changes whenever Python changes the byte
>> co
On Apr 16, 2010, at 2:42 PM, Daniel Stutzbach wrote:
>
> IIRC, there's a performance hack in dictobject.c that keeps track of whether
> all of the keys are strings or not. The hack is designed so that lookup
> operations can call the string compare/hash functions directly if possible,
> rathe
Raymond Hettinger gmail.com> writes:
>
> Would hate for 100% of users will pay a performance penalty
> when most applications aren't abusing keyword dictionaries
> so they already work cross-platfrom.
Someone should provide actual measurements before we start a psychodrama about
Python performa
At 04:51 PM 4/16/2010 -0500, Benjamin Peterson wrote:
That won't work. You could put non-string keys in a dictionary and
remove them, but the dictionary would still be in the less optimized state.
That only means it's slower on uncommon cases and the case where
you're about to get an exception
On Fri, Apr 16, 2010 at 4:51 PM, Benjamin Peterson wrote:
> 2010/4/16 Daniel Stutzbach :
> > IIRC, there's a performance hack in dictobject.c that keeps track of
> whether
> > all of the keys are strings or not. The hack is designed so that lookup
> > operations can call the string compare/hash f
> On Fri, Apr 16, 2010 at 2:11 PM, Raymond Hettinger
> wrote:
>>
Guido van Rossum, 16.04.2010 16:33:
>
> I am fine with
> declaring dict({}, **{1:3}) illegal, since after all it is abuse of
> the ** mechanism.
>>
>> ISTM that making it illegal costs cycles with giving any
2010/4/16 Daniel Stutzbach :
> On Fri, Apr 16, 2010 at 4:11 PM, Raymond Hettinger
> wrote:
>>
>> ISTM that making it illegal costs cycles with giving any real benefit.
>> It is reasonably common to accept **kwds and then pass it down
>> to another function. Do we want to validate the keys of ever
On Fri, Apr 16, 2010 at 4:11 PM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
> ISTM that making it illegal costs cycles with giving any real benefit.
> It is reasonably common to accept **kwds and then pass it down
> to another function. Do we want to validate the keys of every
> kwds
On Fri, Apr 16, 2010 at 2:22 PM, Maciej Fijalkowski wrote:
> On Fri, Apr 16, 2010 at 3:11 PM, Raymond Hettinger
> wrote:
>>
Guido van Rossum, 16.04.2010 16:33:
>
> I am fine with
> declaring dict({}, **{1:3}) illegal, since after all it is abuse of
> the ** mechanism.
>>
>> I
On Fri, Apr 16, 2010 at 3:11 PM, Raymond Hettinger
wrote:
>
>>> Guido van Rossum, 16.04.2010 16:33:
I am fine with
declaring dict({}, **{1:3}) illegal, since after all it is abuse of
the ** mechanism.
>
> ISTM that making it illegal costs cycles with giving any real benefit.
>
On Fri, Apr 16, 2010 at 2:11 PM, Raymond Hettinger
wrote:
>
>>> Guido van Rossum, 16.04.2010 16:33:
I am fine with
declaring dict({}, **{1:3}) illegal, since after all it is abuse of
the ** mechanism.
>
> ISTM that making it illegal costs cycles with giving any real benefit.
D
2010/4/16 Raymond Hettinger :
>
>>> Guido van Rossum, 16.04.2010 16:33:
I am fine with
declaring dict({}, **{1:3}) illegal, since after all it is abuse of
the ** mechanism.
>
> ISTM that making it illegal costs cycles with giving any real benefit.
> It is reasonably common to ac
>> Guido van Rossum, 16.04.2010 16:33:
>>>
>>> I am fine with
>>> declaring dict({}, **{1:3}) illegal, since after all it is abuse of
>>> the ** mechanism.
ISTM that making it illegal costs cycles with giving any real benefit.
It is reasonably common to accept **kwds and then pass it down
to ano
I am aware my email has gone out multiple times. My phone kept saying that
it was not sent, so I kept trying to force it to send. Sorry about the extra
emails.
On Fri, Apr 16, 2010 at 10:50, Brett Cannon wrote:
> Yes, we have different opinions. My personal take is to wait a week before
> you em
2010/4/16 Barry Warsaw :
> On Apr 15, 2010, at 08:01 PM, Guido van Rossum wrote:
>>> This feature is targeted for Python 3.2, solving the problem for those
>>> and all future versions. It may be back-ported to Python 2.7.
>>
>>Is there time given that 2.7b1 was released?
>
> I think this would be
On Fri, Apr 16, 2010 at 11:09 AM, Terry Reedy wrote:
> On 4/15/2010 11:01 PM, Guido van Rossum wrote:
>>>
>>> pyc files inside of the `__pycache__` directories contain a magic
>>> identifier in their file names. These are mnemonic tags for the
>>> actual magic numbers used by the importer. For e
Brian Curtin wrote:
> Hi python-dev,
>
> The recent threads on builds/installers for Mac and Windows reminded me
> of Steve Holden's push to get the python-dev team equipped via a
> connection with the Microsoft Open Source Technology Center. The OSTC
> team provides Microsoft Developer Network li
On 4/16/2010 11:22 AM, Dino Viehland wrote:
Mark Dickinson wrote:
Removing it certainly seems in keeping with the goal of making life
easier for alternate implementations. (Out of curiosity, does anyone
know what IronPython does here?)
I've opened http://bugs.python.org/issue8419
It looks l
On 4/15/2010 11:01 PM, Guido van Rossum wrote:
pyc files inside of the `__pycache__` directories contain a magic
identifier in their file names. These are mnemonic tags for the
actual magic numbers used by the importer. For example, in Python
3.2, we could use the hexlified [10]_ magic number a
Yes, we have different opinions. My personal take is to wait a week before
you email python-dev if there has been no activity. That is enough time for
people interested in the patch to get to it as we all have different
schedules. Any faster and it feels like noise on the list to me.
Brett (from h
On Fri, Apr 16, 2010 at 8:22 AM, Ronald Oussoren wrote:
>
> On Friday, April 16, 2010, at 04:57PM, "Antoine Pitrou"
> wrote:
>>Mark Dickinson gmail.com> writes:
>>>
>>> Okay; I'll open an issue for deprecation in 3.2 and removal in 3.3.
>>>
>>> Can this sneak in under the 'incorrect language s
On Fri, Apr 16, 2010 at 8:35 AM, Stefan Behnel wrote:
> Guido van Rossum, 16.04.2010 16:33:
>>
>> I am fine with
>> declaring dict({}, **{1:3}) illegal, since after all it is abuse of
>> the ** mechanism.
>
> It's a bit like letting keys like 'not-an-identifier' pass through, though,
> isn't it?
ACTIVITY SUMMARY (2010-04-09 - 2010-04-16)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
2658 open (+38) / 17582 closed (+25) / 20240 total (+63)
Open issues with patches: 1090
Ave
On Apr 15, 2010, at 08:01 PM, Guido van Rossum wrote:
>Comments inline. Nothing showstopping, mostly just spewing obscure
>background information...
>
>Overall, congratulations! I'm fine with the implementation going in
>and the PEP being marked as accepted as long as you get to the
>clarification
Guido van Rossum, 16.04.2010 16:33:
I am fine with
declaring dict({}, **{1:3}) illegal, since after all it is abuse of
the ** mechanism.
It's a bit like letting keys like 'not-an-identifier' pass through, though,
isn't it?
Stefan
___
Python-Dev ma
Mark Dickinson wrote:
> Removing it certainly seems in keeping with the goal of making life
> easier for alternate implementations. (Out of curiosity, does anyone
> know what IronPython does here?)
>
> I've opened http://bugs.python.org/issue8419
It looks like IronPython reports a type error a
On Friday, April 16, 2010, at 04:57PM, "Antoine Pitrou"
wrote:
>Mark Dickinson gmail.com> writes:
>>
>> Okay; I'll open an issue for deprecation in 3.2 and removal in 3.3.
>>
>> Can this sneak in under the 'incorrect language semantics' exemption
>> for PEP 3003 (the moratorium PEP)? If no
On 16/04/2010 17:06, Mark Dickinson wrote:
On Fri, Apr 16, 2010 at 3:57 PM, Antoine Pitrou wrote:
Mark Dickinson gmail.com> writes:
Okay; I'll open an issue for deprecation in 3.2 and removal in 3.3.
Can this sneak in under the 'incorrect language semantics' exemption
for PEP 300
On Fri, Apr 16, 2010 at 3:57 PM, Antoine Pitrou wrote:
> Mark Dickinson gmail.com> writes:
>>
>> Okay; I'll open an issue for deprecation in 3.2 and removal in 3.3.
>>
>> Can this sneak in under the 'incorrect language semantics' exemption
>> for PEP 3003 (the moratorium PEP)? If not, then depr
Mark Dickinson gmail.com> writes:
>
> Okay; I'll open an issue for deprecation in 3.2 and removal in 3.3.
>
> Can this sneak in under the 'incorrect language semantics' exemption
> for PEP 3003 (the moratorium PEP)? If not, then deprecation
> presumably has to wait for 3.3.
It seems that in s
On Fri, Apr 16, 2010 at 12:57 AM, Alex Gaynor wrote:
> Hi all,
>
> I ran into the follow behavior while making sure Django works
> correctly on PyPy. The following behavior was observed in all tested
> versions of CPython (2.5, 3.1):
>
def f(**kwargs):
> ... print(kwargs)
> ...
kwar
On Fri, Apr 16, 2010 at 3:33 PM, Guido van Rossum wrote:
> On Fri, Apr 16, 2010 at 7:15 AM, Nick Coghlan wrote:
>> I would agree with leaving it implementation defined - I don't think
>> either PyPy or CPython should be forced to change their current
>> behaviour in relation to this. A minor note
On Fri, Apr 16, 2010 at 7:15 AM, Nick Coghlan wrote:
> Mark Dickinson wrote:
>> "dict(x, **y)" as an expression version of x.update(y) seems to be
>> fairly well known[1], so disallowing non-string keyword arguments
>> seems likely to break existing code, as well as (probably?) harming
>> performa
Mark Dickinson wrote:
> "dict(x, **y)" as an expression version of x.update(y) seems to be
> fairly well known[1], so disallowing non-string keyword arguments
> seems likely to break existing code, as well as (probably?) harming
> performance. So I can't see CPython changing here. I'm not sure
>
Hi python-dev,
The recent threads on builds/installers for Mac and Windows reminded me of
Steve Holden's push to get the python-dev team equipped via a connection
with the Microsoft Open Source Technology Center. The OSTC team provides
Microsoft Developer Network licenses to open source projects t
On Fri, Apr 16, 2010 at 11:03:30AM +, Antoine Pitrou wrote:
>
> It shouldn't have been committed to 3.1, though. Could you revert?
Yeah, I had this doubt. Okay, I shall revert it from 3.1 branch.
--
Senthil
___
Python-Dev mailing list
Python-Dev@p
Senthil Kumaran gmail.com> writes:
>
> http://bugs.python.org/issue2987
>
> This deals with a feature request of parsing an IPv6 URL according to
> standards. The patch is pretty complete and we have good test coverage
> too.
>
> Is it okay to include this in Python 2.7 b2 release? It would b
On Fri, Apr 16, 2010 at 9:04 AM, Hagen Fürstenau wrote:
>> This behavior seems pretty strange to me, indeed PyPy gives the
>> TypeError for both attempts. I just wanted to confirm that it was in
>> fact intentional.
>
> Oleg already answered why f(**{1:3}) raises a TypeError. But your
> question
> This behavior seems pretty strange to me, indeed PyPy gives the
> TypeError for both attempts. I just wanted to confirm that it was in
> fact intentional.
Oleg already answered why f(**{1:3}) raises a TypeError. But your
question seems to be rather why dict(**{1:3}) doesn't.
For functions impl
On Fri, Apr 16, 2010 at 12:57:06AM -0400, Alex Gaynor wrote:
> >>> def f(**kwargs):
> ... print(kwargs)
> ...
> >>> kwargs = {1: 3}
> >>>
> >>> dict({}, **kwargs)
> {1: 3}
> >>> f(**kwargs)
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: f() keywords must be strings
Hi all,
I ran into the follow behavior while making sure Django works
correctly on PyPy. The following behavior was observed in all tested
versions of CPython (2.5, 3.1):
>>> def f(**kwargs):
... print(kwargs)
...
>>> kwargs = {1: 3}
>>>
>>> dict({}, **kwargs)
{1: 3}
>>> f(**kwargs)
Tracebac
51 matches
Mail list logo
