[Python-Dev] Very Strange Argument Handling Behavior

[Alex Gaynor]

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)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: f() keywords must be strings
>>>


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.

Thanks,
Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- 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] Very Strange Argument Handling Behavior

[Oleg Broytman]

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

   Argument names must be strings. In your example 1 must be at least '1'.

Oleg.
-- 
 Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru
   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] Very Strange Argument Handling Behavior

[Hagen Fürstenau]

> 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 implemented in Python, non-string arguments are always
rejected, but C functions (like the dict constructor) don't have to
reject them. I don't see any benefit in allowing them, but it's probably
not worth breaking code by disallowing them either.

I couldn't find this documented. Perhaps we should just say "don't rely
on being able to pass non-string keywords" somewhere?

- Hagen
___
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] Very Strange Argument Handling Behavior

[Mark Dickinson]

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 seems to be rather why dict(**{1:3}) doesn't.
>
> For functions implemented in Python, non-string arguments are always
> rejected, but C functions (like the dict constructor) don't have to
> reject them. I don't see any benefit in allowing them, but it's probably
> not worth breaking code by disallowing them either.

"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
whether other implementations should be required to follow suit,
though---maybe this should be regarded as an implementation-defined
detail?

Mark

[1] 
http://stackoverflow.com/questions/38987/how-can-i-merge-two-python-dictionaries-as-a-single-expression
)
___
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] urlparse - to parse IPv6 URL in 2.7 b2 ?

[Antoine Pitrou]

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 be a
> worthy addition.
> 

It shouldn't have been committed to 3.1, though. Could you revert?

Thanks

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/archive%40mail-archive.com

Re: [Python-Dev] urlparse - to parse IPv6 URL in 2.7 b2 ?

[Senthil Kumaran]

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@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] MSDN licenses available for python-dev

[Brian Curtin]

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 to assist them
in better supporting Windows.

I've talked with Steve (who passed the task to me) and the Microsoft folks,
and they are happy to provide more licenses if needed. If you are interested
in getting a copy of MSDN, please contact me off-list. I'll provide you with
a code that you'll put into their site, then around a week later you should
get your subscription.

The snippet below is taken from prior correspondence with the OSTC team in
regards to who can receive the licenses:

"""
For the purposes of providing MSDN licenses to an open source development
community, I consider anyone who writes, builds, tests or documents software
to be a "developer who contributes" to the project. (In fact, having started
out as a test engineer, I would take exception to anyone who claimed only
people who write code are "developers" :-) We do ask that requests are for
people who are active contributors and not just minor/occasional
participants.
"""

If this applies to you and you are interested, let me know.

Brian Curtin
___
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] Very Strange Argument Handling Behavior

[Nick Coghlan]

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
> whether other implementations should be required to follow suit,
> though---maybe this should be regarded as an implementation-defined
> detail?

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 in the language reference to
that effect may be worthwhile just to make that stance official.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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] Very Strange Argument Handling Behavior

[Guido van Rossum]

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
>> performance.  So I can't see CPython changing here.  I'm not sure
>> whether other implementations should be required to follow suit,
>> though---maybe this should be regarded as an implementation-defined
>> detail?
>
> 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 in the language reference to
> that effect may be worthwhile just to make that stance official.

That is just going to cause some programs to have a portability
surprise. I think one or the other should be fixed. I am fine with
declaring dict({}, **{1:3}) illegal, since after all it is abuse of
the ** mechanism. We should deprecate it in at least one version
though.

-- 
--Guido van Rossum (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] Very Strange Argument Handling Behavior

[Mark Dickinson]

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 in the language reference to
>> that effect may be worthwhile just to make that stance official.
>
> That is just going to cause some programs to have a portability
> surprise. I think one or the other should be fixed. I am fine with
> declaring dict({}, **{1:3}) illegal, since after all it is abuse of
> the ** mechanism. We should deprecate it in at least one version
> though.

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.

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] Very Strange Argument Handling Behavior

[Raghuram Devarakonda]

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)
> ...
 kwargs = {1: 3}

 dict({}, **kwargs)
> {1: 3}
 f(**kwargs)
> Traceback (most recent call last):
>  File "", line 1, in 
> TypeError: f() keywords must be strings

>
>
> 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.

I ran into same issue with Django on Jython yesterday [1] since Jython
too gives TypeError for 'dict({}, **kwargs)'.

Thanks,
Raghu

[1] http://bugs.jython.org/issue1600
___
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] Very Strange Argument Handling Behavior

[Antoine Pitrou]

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 spirit the moratorium applies more to language additions than
to removals/limitations. The goal being that alternate implementation stop
chasing a moving target in terms of features.

So IMVHO it is fine for 3.2.

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/archive%40mail-archive.com

Re: [Python-Dev] Very Strange Argument Handling Behavior

[Mark Dickinson]

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 deprecation
>> presumably has to wait for 3.3.
>
> It seems that in spirit the moratorium applies more to language additions than
> to removals/limitations. The goal being that alternate implementation stop
> chasing a moving target in terms of features.
>
> So IMVHO it is fine for 3.2.

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

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] Very Strange Argument Handling Behavior

[Michael Foord]

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 3003 (the moratorium PEP)?  If not, then deprecation
presumably has to wait for 3.3.
   

It seems that in spirit the moratorium applies more to language additions than
to removals/limitations. The goal being that alternate implementation stop
chasing a moving target in terms of features.

So IMVHO it is fine for 3.2.
 

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?)
   


Same as Jython and PyPy:

IronPython 2.6.1 (2.6.10920.0) on .NET 2.0.50727.4927
Type "help", "copyright", "credits" or "license" for more information.
>>> dict(**{1: 'hi'})
Traceback (most recent call last):
  File "", line 1, in 
TypeError: expected string for dictionary argument got 1
>>>

Michael


I've opened http://bugs.python.org/issue8419

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/fuzzyman%40voidspace.org.uk
   



--
http://www.ironpythoninaction.com/

___
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] Very Strange Argument Handling Behavior

[Ronald Oussoren]

 
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 not, then deprecation
>> presumably has to wait for 3.3.
>
>It seems that in spirit the moratorium applies more to language additions than
>to removals/limitations. The goal being that alternate implementation stop
>chasing a moving target in terms of features.
>
>So IMVHO it is fine for 3.2.

What about 2.7, should it be deprecated there as well?

Ronald

___
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] Very Strange Argument Handling Behavior

[Dino Viehland]

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 as well:

IronPython 2.6.1 DEBUG (2.6.10920.0) on .NET 2.0.50727.4927
Type "help", "copyright", "credits" or "license" for more information.
>>> def f(**kwargs):
... print(kwargs)
...
>>> kwargs = {1: 3}
>>>
>>> dict({}, **kwargs)
Traceback (most recent call last):
  File "", line unknown, in 
TypeError: expected string for dictionary argument got 1
>>> d = {1:2}
>>> d.update({3:4}, **{5:6})
Traceback (most recent call last):
  File "", line unknown, in 
TypeError: expected string for dictionary argument got 5



___
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] Very Strange Argument Handling Behavior

[Stefan Behnel]

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 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] PEP 3147 ready for pronouncement and merging

[Barry Warsaw]

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
>clarifications I suggest below soon after.

Awesome, thanks Guido!  I will respond in detail and address your
clarifications before I commit to the py3k branch.  I wanted to address one
thing now though since Steve responded to it.

>> Implementation strategy
>> ===
>>
>> 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 totally up to Benjamin as the RM for 2.7.  Although I
haven't tried yet, my sense of it is that most of the patch would port pretty
easily to trunk.  I could probably generate a patch for review by mid-next
week.

Whether it should or not is a different matter.  Given that we're in beta, I'm
not sure *I* would approve it if I were the RM, but as the developer, sure,
I'd love to back port it. :)

However...

>> Vendors are free to backport the changes to earlier distributions as
>> they see fit.

...Steve asks if we're really going to do this.  For Debian and/or Ubuntu, we
haven't yet decided.  I plan to begin that discussion on the appropriate
distro-related mailing lists after the code lands on py3k.  It certainly won't
be enabled by default.

I don't think we've made any decisions about which versions of Python will
make it into the next release of Ubuntu about 6 months from now, but given the
Python release schedule, that could be 2.6, 2.7 and 3.1.  If we really do
include all three versions, I will push for backporting the feature (enabled
with -Xcachedir) in our releases so that we can gain the benefit of ditching
the symlink farms as soon as possible.

-Barry


signature.asc
Description: 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

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

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

Average duration of open issues: 728 days.
Median duration of open issues: 492 days.

Open Issues Breakdown
   open  2616 (+38)
languishing 9 ( +0)
pending32 ( +0)

Issues Created Or Reopened (68)
___

Add "key" argument to "bisect" module functions2010-04-14
   http://bugs.python.org/issue4356reopened rhettinger  
  
   patch   

AttributeError: MSVCCompiler instance has no attribute '_MSVCC 2010-04-13
   http://bugs.python.org/issue7509reopened tarek   
  
   

configure: ignore AC_PROG_CC hardcoded CFLAGS  2010-04-11
   http://bugs.python.org/issue8211reopened lemburg 
  
   patch   

test_ctypes fails in test_ulonglong on sparc buildbots 2010-04-12
   http://bugs.python.org/issue8314reopened pitrou  
  
   patch, buildbot 

Add a --show-installation-paths in the install command 2010-04-09
   http://bugs.python.org/issue8357reopened tarek   
  
   

absolute_import future directive ignored by 2to3   2010-04-09
CLOSED http://bugs.python.org/issue8358created  jaraco  
  
   

% formating - TypeError: not all arguments converted during st 2010-04-10
CLOSED http://bugs.python.org/issue8359created  sneetsher   
  
   

doc: unittest.skipTest method added in 2.7 2010-04-10
CLOSED http://bugs.python.org/issue8360created  techtonik   
  
   patch   

Remove assert in functools.total_ordering  2010-04-10
CLOSED http://bugs.python.org/issue8361created  merwok  
  
   patch   

Add Misc/maintainers.rst to 2.x branch 2010-04-10
   http://bugs.python.org/issue8362created  merwok  
  
   patch, needs review 

Lots of duplicate code between test_classify_oldstyle and test 2010-04-10
CLOSED http://bugs.python.org/issue8363created  exarkun 
  
   patch, needs review 

Update site.setquit docstring  2010-04-10
CLOSED http://bugs.python.org/issue8364created  merwok  
  
   patch   

'readline' module fails to build on OS X - some recent change  2010-04-11
CLOSED http://bugs.python.org/issue8365created  l0nwlf  
  
   

OS X universal builds fail on 2.7b1 and py3k with "Don't know  2010-04-11
   http://bugs.python.org/issue8366created  ned.deily   
  
   

test_winsound: failure on systems without soundcard2010-04-11
CLOSED http://bugs.python.org/issue8367created  skrah   
  
   patch   

Memory leak on multi-threaded PyObject_CallObject  2010-04-11
CLOSED http://bugs.python.org/issue8368created  Krauzi  
  
   

Add a lint command to distutils2010-04-11
   http://bugs.python.org/issue8369created  merwok  
  
   

change module "builtins" to "__builtin__" in __import__ docume 2010-04-11
CLOSED http://bugs.python.org/issue8370created  cjerdonek   
  
   patch   

Add a command to download distributions2010-04-11
   ht

Re: [Python-Dev] Very Strange Argument Handling Behavior

[Guido van Rossum]

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?

Not really. It's hard to imagine(*) an implementation that naturally
can represent strings that look like identifiers but not other strings
-- typically, "identifier-ness" must be explicitly checked. But it's
easy to imagine an implementation that only allows strings and not
other values.

___
(*) I didn't say impossible. I don't really care about any
counter-examples you may come up with -- in practice they don't
matter. But the type *does* matter in practice.

-- 
--Guido van Rossum (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] Very Strange Argument Handling Behavior

[Guido van Rossum]

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 semantics' exemption
>>> for PEP 3003 (the moratorium PEP)?  If not, then deprecation
>>> presumably has to wait for 3.3.
>>
>>It seems that in spirit the moratorium applies more to language additions than
>>to removals/limitations. The goal being that alternate implementation stop
>>chasing a moving target in terms of features.
>>
>>So IMVHO it is fine for 3.2.
>
> What about 2.7, should it be deprecated there as well?

I think so. Compatibility with PyPy, Jython and IronPython is only
going to become more important.

-- 
--Guido van Rossum (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] patch for review: __import__ documentation

[Brett Cannon]

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 his phone)

On Apr 14, 2010 11:28 PM, "Glyph Lefkowitz"  wrote:

On Apr 14, 2010, at 5:19 PM, Brett Cannon wrote:

> I see the confusion. I think Martin meant more about open issues that
required discussion, not sim...

Ach.  I hit 'send' too soon.  I also wanted to say: it seemed quite clear to
me that Martin specifically meant "simply issues that had a patch ready to
go".  Quoting him exactly:

Please understand that setting the state of an issue to "review" may
*not* be the best way to trigger a review - it may be more effective
to post to python-dev if you truly believe that the patch can be
committed as-is.

It seems that perhaps the core developers have slightly different opinions
about this? :)
___
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] PEP 3147 ready for pronouncement and merging

[Terry Reedy]

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 as a unique


(Aside: when you search Wikipedia for "hexlify" it says "did you mean:
heavily?" :-)


I regard 'hexlify', as used in binascii, to be a misspelling of 
'hexify', whether it originated with Python or elsewhere. 'Hexify' 
itself may not be an official dictionary word but it at least follows a 
normal pattern of derivation. I have not bothered to say anything before 
because correcting the misspelling of the module function would break 
back compatibility. But I think its usage should stop there.


Terry Jan Reedy

___
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] Very Strange Argument Handling Behavior

[Terry Reedy]

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 like IronPython reports a type error as well:

IronPython 2.6.1 DEBUG (2.6.10920.0) on .NET 2.0.50727.4927
Type "help", "copyright", "credits" or "license" for more information.

def f(**kwargs):

... print(kwargs)
...

kwargs = {1: 3}

dict({}, **kwargs)

Traceback (most recent call last):
   File "", line unknown, in
TypeError: expected string for dictionary argument got 1

d = {1:2}
d.update({3:4}, **{5:6})

Traceback (most recent call last):
   File "", line unknown, in
TypeError: expected string for dictionary argument got 5


If the current CPython behavior is deprecated in 3.2, then I think 
IronPython should keep its current behavior (and future Cpython 
behavior) in IP 3.2 and not change it for one version.


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] MSDN licenses available for python-dev

[Steve Holden]

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 licenses to open source
> projects to assist them in better supporting Windows.
> 
>[...]
> If this applies to you and you are interested, let me know.
> 
Thanks, Brian, for taking this on.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
See PyCon Talks from Atlanta 2010  http://pycon.blip.tv/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/

___
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] PEP 3147 ready for pronouncement and merging

[Guido van Rossum]

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 example, in Python
>>> 3.2, we could use the hexlified [10]_ magic number as a unique
>>
>> (Aside: when you search Wikipedia for "hexlify" it says "did you mean:
>> heavily?" :-)
>
> I regard 'hexlify', as used in binascii, to be a misspelling of 'hexify',
> whether it originated with Python or elsewhere. 'Hexify' itself may not be
> an official dictionary word but it at least follows a normal pattern of
> derivation. I have not bothered to say anything before because correcting
> the misspelling of the module function would break back compatibility. But I
> think its usage should stop there.

To the contrary, it was invented by Barry and ought to be added to the
English language as a neologism.

-- 
--Guido van Rossum (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] PEP 3147 ready for pronouncement and merging

[Benjamin Peterson]

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 totally up to Benjamin as the RM for 2.7.  Although I
> haven't tried yet, my sense of it is that most of the patch would port pretty
> easily to trunk.  I could probably generate a patch for review by mid-next
> week.

I would prefer that this not be in 2.7. The patch may be simple to
port, but it represents quite a change in an eons old Python behvior.

>
> Whether it should or not is a different matter.  Given that we're in beta, I'm
> not sure *I* would approve it if I were the RM, but as the developer, sure,
> I'd love to back port it. :)

Thank you for sympathizing. :)



-- 
Regards,
Benjamin
___
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] patch for review: __import__ documentation

[Brett Cannon]

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 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 his phone)
>
> On Apr 14, 2010 11:28 PM, "Glyph Lefkowitz" 
> wrote:
>
> On Apr 14, 2010, at 5:19 PM, Brett Cannon wrote:
>
> > I see the confusion. I think Martin meant more about open issues that
> required discussion, not sim...
>
> Ach.  I hit 'send' too soon.  I also wanted to say: it seemed quite clear
> to me that Martin specifically meant "simply issues that had a patch ready
> to go".  Quoting him exactly:
>
> Please understand that setting the state of an issue to "review" may *not* be 
> the best way to trigger a review - it may be more effective to post to 
> python-dev if you truly believe that the patch can be committed as-is.
>
> It seems that perhaps the core developers have slightly different opinions
> about this? :)
>
>
___
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] Very Strange Argument Handling Behavior

[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 accept **kwds and then pass it down
to another function.  Do we want to validate the keys of every
kwds dict on every call?  Why do we even care?

If I'm understanding the proposal correctly, it means that
every existing application using **kwds will pay a price, either
by breaking (because it uses non-string keys) or by running
slower (so that every call can be checked to make sure it
didn't use string keys).


Raymond

___
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] Very Strange Argument Handling Behavior

[Benjamin Peterson]

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 accept **kwds and then pass it down
> to another function.  Do we want to validate the keys of every
> kwds dict on every call?  Why do we even care?
>
> If I'm understanding the proposal correctly, it means that
> every existing application using **kwds will pay a price, either
> by breaking (because it uses non-string keys) or by running
> slower (so that every call can be checked to make sure it
> didn't use string keys).

We already pay that price for any Python function, so I'm not sure
what difference adding to C, too, makes.



-- 
Regards,
Benjamin
___
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] Very Strange Argument Handling Behavior

[Guido van Rossum]

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.

Diasagree. The real benefit is better cross-implementation portability.

> 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 dict on every call?  Why do we even care?
>
> If I'm understanding the proposal correctly, it means that
> every existing application using **kwds will pay a price, either
> by breaking (because it uses non-string keys) or by running
> slower (so that every call can be checked to make sure it
> didn't use string keys).

It already does this for Python functions. So there is no cost (and no
change in the language semantics) except for the specific idiom
involving dict, which was incorrectly taking a shortcut.

-- 
--Guido van Rossum (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] Very Strange Argument Handling Behavior

[Maciej Fijalkowski]

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.
> 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 dict on every call?  Why do we even care?
>
> If I'm understanding the proposal correctly, it means that
> every existing application using **kwds will pay a price, either
> by breaking (because it uses non-string keys) or by running
> slower (so that every call can be checked to make sure it
> didn't use string keys).
>
>
> Raymond
>

On the other hand, we (as in alternative python implementations) are
paying the price because people use it, even if only accidentally. If
CPython detects such cases and complain early, it would be much easier
for applications to stay cross-interpreter compatible (and I don't
think it's a huge burden for them to get rid of that, django already
did).

Cheers,
fijal
___
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] Very Strange Argument Handling Behavior

[Guido van Rossum]

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.
>>
>> 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 dict on every call?  Why do we even care?
>>
>> If I'm understanding the proposal correctly, it means that
>> every existing application using **kwds will pay a price, either
>> by breaking (because it uses non-string keys) or by running
>> slower (so that every call can be checked to make sure it
>> didn't use string keys).
>>
>>
>> Raymond
>>
>
> On the other hand, we (as in alternative python implementations) are
> paying the price because people use it, even if only accidentally. If
> CPython detects such cases and complain early, it would be much easier
> for applications to stay cross-interpreter compatible (and I don't
> think it's a huge burden for them to get rid of that, django already
> did).

+1.

Apparently dict(x, **y) is going around as "cool hack" for "call
x.update(y) and return x". Personally I find it more despicable than
cool.

-- 
--Guido van Rossum (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] Very Strange Argument Handling Behavior

[Daniel Stutzbach]

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 dict on every call?  Why do we even care?
>

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,
rather than going through the slower PyObject_ functions.

Consequently, validating **kwds should be cheap.

I don't know if the the current validating of **kwds with Python functions
already leverages that hack or not.
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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] Very Strange Argument Handling Behavior

[Benjamin Peterson]

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 every
>> kwds dict on every call?  Why do we even care?
>
> 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,
> rather than going through the slower PyObject_ functions.
>
> Consequently, validating **kwds should be cheap.

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.



-- 
Regards,
Benjamin
___
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] Very Strange Argument Handling Behavior

[Raymond Hettinger]

> 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.
> 
> Diasagree. The real benefit is better cross-implementation portability.

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.

Isn't there anyway to make this a one-time check instead
of a PyLint style validation check running on every invocation
of a function or method using **kwds?

Or perhaps there can be a switch or flag to enable developers to
check for non-standard uses of **kwds.  That way, they can clean-up
their programs but not make the end users pay for the checks every time
they run an application that has already been cleaned-up.


Raymond
___
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] Very Strange Argument Handling Behavior

[Daniel Stutzbach]

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 functions directly if
> possible,
> > rather than going through the slower PyObject_ functions.
>
> 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.
>

It would be enough to make the common case fast (1 pointer comparison).  The
error case would need to check all of the keys, true, but that's not really
a performance concern.

Unless you're saying you often create a dictionary, add non-string keys,
remove the non-string keys, then pass it as a **kwds? ;-)
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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] Very Strange Argument Handling Behavior

[P.J. Eby]

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 anyway. 


___
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] Very Strange Argument Handling Behavior

[Antoine Pitrou]

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 performance being brutally butchered and chopped into small pieces on the
altar of inter-implementation compatibility ;)

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/archive%40mail-archive.com

Re: [Python-Dev] Very Strange Argument Handling Behavior

[Raymond Hettinger]

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, 
> rather than going through the slower PyObject_ functions.
> 
> Consequently, validating **kwds should be cheap.
> 

Good thinking.

That would definitely be better than scanning the full dict on every call.


Raymond


___
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] PEP 3147 ready for pronouncement and merging

[Barry Warsaw]

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
>> code format, e.g. by adding new byte codes to its virtual machine.
>> This ensures that pyc files built for previous versions of the VM
>> won't cause problems.  The timestamp is used to make sure that the pyc
>> file is not older than the py file that was used to create it.  When
>
>is not older than -> matches
>
>(Obscure fact: the timestamp in the pyc file must match the source's
>mtime exactly.)

Done.

>> Rationale
>> =
>>
>> Linux distributions such as Ubuntu [4]_ and Debian [5]_ provide more
>> than one Python version at the same time to their users.  For example,
>> Ubuntu 9.10 Karmic Koala users can install Python 2.5, 2.6, and 3.1,
>> with Python 2.6 being the default.
>>
>> This causes a conflict for Python source files installed by the
>> system (including third party packages), because you cannot compile a
>
>I'd say only 3rd part packages right? (And code written by the distro,
>which from Python's POV is also 3rd party.) At least ought to clarify
>that the stdlib is unaffected by this conflict, because multiple
>versions of the stdlib *are* installed.

Yes, good point.  Clarified.

>> single Python source file for more than one Python version at a time.
>> Thus if your system wanted to install a `/usr/share/python/foo.py`, it
>> could not create a `/usr/share/python/foo.pyc` file usable across all
>> installed Python versions.
>
>Note that (due to the magic#) Python doesn't crash, it just falls back
>on the slower approach of compiling from source.
>
>Perhaps more important is that different Python versions (if the user
>has write permission) will fight over the pyc file and rewrite it each
>time the source is compiled. Worse, even though the magic# is
>initially written as zero and then rewritten with the correct value,
>concurrent processes running different Python versions can actually
>end up reading corrupt bytecode. (Alex Martelli diagnosed this at
>Google years ago.)

Good point; I've made this more clear.

>> Furthermore, in order to ease the burden on operating system packagers
>> for these distributions, the distribution packages do not contain
>> Python version numbers [6]_; they are shared across all Python
>> versions installed on the system.  Putting Python version numbers in
>> the packages would be a maintenance nightmare, since all the packages
>> - *and their dependencies* - would have to be updated every time a new
>> Python release was added or removed from the distribution.  Because of
>> the sheer number of packages available, this amount of work is
>> infeasible.
>>
>> C extensions can be source compatible across multiple versions of
>> Python.  Compiled extension modules are usually not compatible though,
>
>Actually we typically make every effort to support backwards
>compatibility for compiled modules, and the module initialization API
>contains a version# check. This is a different version# than the
>import magic# and historically has changed much less frequently.

I've rewritten this paragraph a bit.  It's not particularly relevant to this
PEP. (I'll be look at PEP 384 soon.)

>> and PEP 384 [7]_ has been proposed to address this by defining a
>> stable ABI for extension modules.
>>

>> Proposal
>> 
>>
>> Python's import machinery is extended to write and search for byte
>> code cache files in a single directory inside every Python package
>> directory.  This directory will be called `__pycache__`.
>> Further, pyc files will contain a magic string that differentiates the
>
>Clarify that the magic string is in the filename, not in the file contents.

Yep.

>> Python version they were compiled for.  This allows multiple byte
>> compiled cache files to co-exist for a single Python source file.
>>
>> This scheme has the added benefit of reducing the clutter in a Python
>> package directory.
>>
>> When a Python source file is imported for the first time, a
>> `__pycache__` directory will be created in the package directory, if
>
>Is this still true? ISTR there was a lot of discussion about the
>auto-creation and possible security concerns.

It is still true.  I think we determined it will usually not be an issue
because the umask will not be altered, and because normal installation
procedures typically involve byte compilation (and thus __pycache__ creation)
during installation time via tools like compileall.  This really is describing
what happens when you run Python over pure Python source code for the first
time, and it's no different from what happens now with the automatic creation
of pyc files.

>> one does not already exist.  The pyc file for the imported source will
>> be written to the `__pycache__` directory, using the magic-tag
>
>By now the magic-tag

Re: [Python-Dev] PEP 3147 ready for pronouncement and merging

[Barry Warsaw]

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
___
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] Very Strange Argument Handling Behavior

[Steve Holden]

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
>> directly if possible, rather than going through the slower PyObject_
>> functions.
>>
>> Consequently, validating **kwds should be cheap.
>>
> Good thinking.
> 
> That would definitely be better than scanning the full dict on every call.
> 
I'm sure we wouldn't want to go so far as to inhibit this. (Py 3.1)

>>> def f(**kwargs):
...   kwargs[1] = "dummy"
...   print(kwargs)
...
>>> f(this="Guido", that="Raymond", the_other="Steve")
{'this': 'Guido', 1: 'dummy', 'the_other': 'Steve', 'that': 'Raymond'}
>>>

Or would we? If it's OK to mutate kwargs inside the function to contain
a non-string key, why isn't it OK to pass a non-string key in?

I understand that it couldn't be generated using keyword argument
syntax, but I don't see why we discriminate against f(**dict(...)) to
limit it to what could be generated using keyword argument syntax. Is
this such a big deal?

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
See PyCon Talks from Atlanta 2010  http://pycon.blip.tv/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/

___
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] Very Strange Argument Handling Behavior

[Michael Foord]

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 call the string compare/hash functions
directly if possible, rather than going through the slower PyObject_
functions.

Consequently, validating **kwds should be cheap.

   

Good thinking.

That would definitely be better than scanning the full dict on every call.

 

I'm sure we wouldn't want to go so far as to inhibit this. (Py 3.1)

   

def f(**kwargs):
 

...   kwargs[1] = "dummy"
...   print(kwargs)
...
   

f(this="Guido", that="Raymond", the_other="Steve")
 

{'this': 'Guido', 1: 'dummy', 'the_other': 'Steve', 'that': 'Raymond'}
   
 

Or would we?

Nobody is proposing barring that.


  If it's OK to mutate kwargs inside the function to contain
a non-string key, why isn't it OK to pass a non-string key in?

   

Because they are completely different operations.

Michael


I understand that it couldn't be generated using keyword argument
syntax, but I don't see why we discriminate against f(**dict(...)) to
limit it to what could be generated using keyword argument syntax. Is
this such a big deal?

regards
  Steve
   



--
http://www.ironpythoninaction.com/

___
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] Drop OS/2 support?

[Victor Stinner]

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. And on IRC we told me that nobody 
knows/uses OS/2.

If we support OS/2, we need a buildbot.

My patch: http://bugs.python.org/issue8391 (os.execvpe() doesn't support 
surrogates in env).

-- 
Victor Stinner
http://www.haypocalc.com/
___
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] Very Strange Argument Handling Behavior

[Greg Ewing]

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 "TypeError: Keyword dict contains non-string
keys", but upon examination, the dict clearly does not contain
any such thing?

--
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] Drop OS/2 support?

[skip]

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
___
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] Very Strange Argument Handling Behavior

[Michael Foord]

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 make of a situation
where Python says "TypeError: Keyword dict contains non-string
keys", but upon examination, the dict clearly does not contain
any such thing?

No, if the dictionary is not marked as an all-string dict it can 
fallback to checking. The common case (dict marked as all strings) is fast.


Michael

--
http://www.ironpythoninaction.com/

___
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] PEP 3147 ready for pronouncement and merging

[Guido van Rossum]

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 not in Python 3).
>
> Do you have a use case for that?  It might be interesting to know, but I can't
> think of a good way to infer that from __file__ and __cached__, or of a good
> way to expose that on module objects.   Of course, it would be totally Python
> implementation dependent too.

The only use case I can think of is a unit test that would indirectly
assess that bytecode was (or wasn't) read in specific conditions. You
can safely ignore this use case.

-- 
--Guido van Rossum (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] Very Strange Argument Handling Behavior

[Guido van Rossum]

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.
>>>
>>> ISTM that making it illegal costs cycles with giving any real benefit.
>>
>> Diasagree. The real benefit is better cross-implementation portability.
>
> 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.
>
> Isn't there anyway to make this a one-time check instead
> of a PyLint style validation check running on every invocation
> of a function or method using **kwds?
>
> Or perhaps there can be a switch or flag to enable developers to
> check for non-standard uses of **kwds.  That way, they can clean-up
> their programs but not make the end users pay for the checks every time
> they run an application that has already been cleaned-up.

Please stop worrying.

-- 
--Guido van Rossum (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] Drop OS/2 support?

[Andrew MacIntyre]

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 contains support for it to be built on OS/2, but 
python.org's normal build process doesn't deliver binaries.


OS/2 lives on as eCS.  It is a second tier platform, akin to Cygwin 
(which also has some source level support but is not part of the normal 
python.org release process).


I'm asking because I'm working on a patch modifying OS2 specific code, but I'm 
unable to compile nor test my changes. And on IRC we told me that nobody 
knows/uses OS/2.

>

If we support OS/2, we need a buildbot.


Build-bots for first tier platforms (Windows, Linux & OS/X) are useful 
for the python.org developer community.


IMO build-bots for secondary platforms are the more the responsibility 
of that platform's community on the basis of best management of 
python.org resources.


I don't think anyone reasonable would expect patch suppliers to deal 
with second tier platforms - I certainly don't.  It is nice to get 
heads-up messages about issues that might involve such support though, 
and it shouldn't take much searching to find me to enquire.


My patch: http://bugs.python.org/issue8391 (os.execvpe() doesn't support 
surrogates in env).


I'll look at it when I get a chance, but I'm not expecting that my input 
should affect your patch and I'm not expecting you to try and deal with 
the issue on OS/2.  The 3.x branch needs quite a bit of work on OS/2 to 
deal with Unicode, as OS/2 was one of the earlier OSes with full 
multiple language support and IBM developed a unique API.  I'm still 
struggling to come to terms with this, partly because I myself don't 
"need" it.


Regards,
Andrew.

--
-
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: andy...@bullseye.apana.org.au  (pref) | Snail: PO Box 370
   andy...@pcug.org.au (alt) |Belconnen ACT 2616
Web:http://www.andymac.org/   |Australia
___
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