Re: [Python-Dev] runpy.py

[Nick Coghlan]

Alexander Belopolsky wrote:
> Take a look at two PEPs referenced in runpy doc,
> http://docs.python.org/3.1/library/runpy.html :
> 
> PEP 338 - Executing modules as scripts
> PEP written and implemented by Nick Coghlan.
> PEP 366 - Main module explicit relative imports
> PEP written and implemented by Nick Coghlan.
> 
> (Nick is too modest to self-reference, but these two PEPs give an
> excellent exposition. :-)

The PEPs don't go into the process of how we actually hook the command
line up to the runpy module though - that's something you need to dig
into the main.c code to really understand.

The command line documentation is also relevant since it defines the
intended behaviour:
http://docs.python.org/dev/using/cmdline.html#command-line

(Drop the /dev from the URL to see the defined behaviour for 2.6)

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] Excluding the current path from module search path?

[Nick Coghlan]

Chris Withers wrote:
> Hi All,
> 
> I'm being bitten by this issue:
> 
> http://bugs.python.org/issue1734860
> 
> I'm not sure I agree with Daniel's closing of it so thought I'd ask here...
> 
> Am I right in thinking that the general idea is that "the current
> working directory at the time of invoking a script or interpreter ends
> up on the python path" or should I be thinking "the directory that a
> script exists in should end up on the python path"?
> 
> If the latter, then what happens in the case of just starting up an
> interpreter?
> 
> If neither, then how come when I have two .py files in a directory, I
> can import one as a module from the other?

The details of the sys.path manipulation at program startup are
documented here:
http://docs.python.org/using/cmdline.html#command-line

The directory prepended to sys.path is based on the code executed by the
command line.

stdin, -c, -m or nothing specified: current directory
Filesystem path pointing to script (source or compiled): directory
containing script
Filesystem path pointing to directory or zipfile: the named directory or
zipfile

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

[Python-Dev] copyright ownership

[Antoine Pitrou]

Guido van Rossum  python.org> writes:
> 
> Are you a lawyer? Do you know the legal history of Python
> distributions and the US export laws? It's not so easy -- for one, the
> PSF (a US foundation) owns the copyright.

Does it? As far as I understand, the contributor agreement is not a copyright
transfer agreement (« PSF understands and agrees that Contributor retains
copyright in its Contributions »).

Not that it makes the issue easier of course :)

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] copyright ownership

[Guido van Rossum]

On Wed, Aug 26, 2009 at 7:44 AM, Antoine Pitrou wrote:
> Guido van Rossum  python.org> writes:
>>
>> Are you a lawyer? Do you know the legal history of Python
>> distributions and the US export laws? It's not so easy -- for one, the
>> PSF (a US foundation) owns the copyright.
>
> Does it? As far as I understand, the contributor agreement is not a copyright
> transfer agreement (« PSF understands and agrees that Contributor retains
> copyright in its Contributions »).

The rights in the individual contributions are retained by the
contributor. However the rights in the distributions as a whole are
most definitely claimed by the PSF. Read the LICENSE file in the
distro. :-)

> Not that it makes the issue easier of course :)

Nothing that involves lawyers is ever easy. That's why well-meaning
suggestions like "but python.org is outside the US" are so aggravating
-- it's so hard to explain why it doesn't work that way.

-- 
--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] PEP 3144: IP Address Manipulation Librar y for the Python Standard Library

[Antoine Pitrou]

DrKJam  gmail.com> writes:
> netaddr employs a simple variant of the GoF Strategy design pattern (with
added Python sensibility).

It would be nice if you could avoid employing this kind of acronyms without
explaining them. Not everybody drinks the design pattern kool-aid.
(Google tells me that GoF seems to mean "Gang of Four", which is of course as
meaningful as a hip-hop band name can be :-))

In any case, if you think netaddr's implementation strategy is better than
ipaddr's, a detailed comparison would be welcome.

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] PEP 3144: IP Address Manipulation Library for the Python Standard Library

[Martin v. Löwis]

>> netaddr employs a simple variant of the GoF Strategy design pattern (with
> added Python sensibility).
> 
> It would be nice if you could avoid employing this kind of acronyms without
> explaining them. Not everybody drinks the design pattern kool-aid.
> (Google tells me that GoF seems to mean "Gang of Four", which is of course as
> meaningful as a hip-hop band name can be :-))
> 
> In any case, if you think netaddr's implementation strategy is better than
> ipaddr's, a detailed comparison would be welcome.

Just in case it still isn't clear "Strategy" above doesn't refer to
"implementation strategy" (i.e. "way of implementing things").

Instead, "Strategy" is a specific design pattern, originally defined by
one of Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides.

See

http://en.wikipedia.org/wiki/Strategy_pattern

for a detailed description. The basic idea is that you can switch
algorithms at run-time, by merely replacing one object with another.

To use it, you define an abstract base class with a method called
"execute". You then create as many subclasses as you want, redefining
"execute" to provide specific *strategies*. You create a (often global)
variable pointing to one instance of the base class, and dynamically
assign this variable with an instance of the appropriate strategy
class. Users of the strategy don't need to know what strategy is chosen.

The wikipedia article points (IMO correctly) out that the Strategy
pattern is mostly useless in languages that have true function pointers,
such as Python. You can still have the global variable part, but you
don't need the abstract base class part at all.

In the specific case of netaddr, I think David is referring to the
netaddr.strategy package, which has modules called ipv4 and ipv6,
both implementing functions like valid_str and str_to_arpa.
Then, class IPAddress has a method reverse_dns, which is defined
as

def reverse_dns(self):
"""The reverse DNS lookup record for this IP address"""
return self._module.int_to_arpa(self._value)

So IPv4 addresses and IPv6 addresses share the same class, but instances
have different values of _module. IPAddress.__init__ looks at the
version keyword parameter if given, otherwise, it tries str_to_int
first for v4, then for v6.

Whether that's better or not than using subclasses, I don't know.

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] PEP 3144: IP Address Manipulation Library for the Python Standard Library

[Ben Finney]

Antoine Pitrou  writes:

> DrKJam  gmail.com> writes:
> > netaddr employs a simple variant of the GoF Strategy design pattern (with
> added Python sensibility).
>
> It would be nice if you could avoid employing this kind of acronyms
> without explaining them. Not everybody drinks the design pattern
> kool-aid.

A pity, since the entire point of Design Patterns is to give us a
vocabulary of terms to use that enable these concepts to be communicated
*without* continually re-defining them. To that extent, then, they fail
their purpose.

-- 
 \“Our wines leave you nothing to hope for.” —restaurant menu, |
  `\   Switzerland |
_o__)  |
Ben Finney

___
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 3144: IP Address Manipulation Library for the Python Standard Library

[Antoine Pitrou]

Martin v. Löwis  v.loewis.de> writes:
> [...]
> Then, class IPAddress has a method reverse_dns, which is defined
> as
> 
> def reverse_dns(self):
> """The reverse DNS lookup record for this IP address"""
> return self._module.int_to_arpa(self._value)
> 
> So IPv4 addresses and IPv6 addresses share the same class, but instances
> have different values of _module.

Ok, thanks for the explanation. It looks like an inheritance-based approach
would allow for easier and more traditional introspection (e.g. `isinstance(ip,
IPv4Address)`). Not to mention that avoiding an indirection level can make
things faster.

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] PEP 3144: IP Address Manipulation Library for the Python Standard Library

[Martin v. Löwis]

>> DrKJam  gmail.com> writes:
>>> netaddr employs a simple variant of the GoF Strategy design pattern (with
>> added Python sensibility).
>>
>> It would be nice if you could avoid employing this kind of acronyms
>> without explaining them. Not everybody drinks the design pattern
>> kool-aid.
> 
> A pity, since the entire point of Design Patterns is to give us a
> vocabulary of terms to use that enable these concepts to be communicated
> *without* continually re-defining them. To that extent, then, they fail
> their purpose.

I think it's too early to tell. It may be that they have not yet
achieved their purpose - just let's wait fifty more years
(and I'm only half-joking).

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] PEP 3144: IP Address Manipulation Library for the Python Standard Library

[Michael Foord]

Antoine Pitrou wrote:

DrKJam  gmail.com> writes:
  

netaddr employs a simple variant of the GoF Strategy design pattern (with


added Python sensibility).

It would be nice if you could avoid employing this kind of acronyms without
explaining them. Not everybody drinks the design pattern kool-aid.
(Google tells me that GoF seems to mean "Gang of Four", which is of course as
meaningful as a hip-hop band name can be :-))
  


Really? Discussing the GoF design patterns by name seems to be prevalent 
amongst the programmers I know (yourself excluded of course...).


Michael


In any case, if you think netaddr's implementation strategy is better than
ipaddr's, a detailed comparison would be welcome.

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



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
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 3144: IP Address Manipulation Library for the Python Standard Library

[Antoine Pitrou]

Michael Foord  voidspace.org.uk> writes:
> 
> Really? Discussing the GoF design patterns by name seems to be prevalent 
> amongst the programmers I know (yourself excluded of course...).

Ah? I still haven't understood what "Gang of Four" is supposed to be, however.
Is it a design pattern?

Besides, saying "I use the strategy design pattern" doesn't tell a lot, while an
ad hoc description is much more informational (witness Martin's explanation for
example).

It's like those frameworks who have a class simply named "Factory" ;)

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] PEP 3144: IP Address Manipulation Library for the Python Standard Library

[Michael Foord]

Antoine Pitrou wrote:

Michael Foord  voidspace.org.uk> writes:
  
Really? Discussing the GoF design patterns by name seems to be prevalent 
amongst the programmers I know (yourself excluded of course...).



Ah? I still haven't understood what "Gang of Four" is supposed to be, however.
Is it a design pattern?
  


The gang of four are the four folk who wrote the classic design patterns 
book:


http://en.wikipedia.org/wiki/Design_Patterns_%28book%29

Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides.

Besides, saying "I use the strategy design pattern" doesn't tell a lot, while an
ad hoc description is much more informational (witness Martin's explanation for
example).

It's like those frameworks who have a class simply named "Factory" ;)
  


Well, depending on the circumstances it can convey some to no 
information. :-)


Michael


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



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
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] 3to2 0.1 alpha 1 released

[Joe Amenta]

Hello all,

I have released the first alpha version of 3to2 after finishing it for my
Google Summer of Code 2009(tm) project.  You can get the tarball for this
release at
http://bitbucket.org/amentajo/lib3to2/downloads/3to2_0.1-alpha1.tar.gz.
This requires python 2.7, because it requires a newer version of 2to3 than
what comes with 2.6.

Release notes are in the RELEASE file.  Development happens at
http://bitbucket.org/amentajo/lib3to2/, and the source code for this release
lives at http://bitbucket.org/amentajo/3to2-01-alpha-1.
Report bugs at http://bitbucket.org/amentajo/lib3to2/issues/, please.

Additional notes and comments can (for now) be found at
http://www.startcodon.com/wordpress/?cat=4.

--Joe
___
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] No 2.4.7 release

[Martin v. Löwis]

I once announced that I would be working on releasing 2.4.7 this month.

However, since no patches have been committed to 2.4.6, there is little
point in making a release. As 2.4 is nearing its end-of-life soon, there
likely won't be any 2.4.7 release.

Python 2.5 has seen only two patches since 2.5.4. However, since several
months have been passed since that release, I'll be creating a 2.5.5
release candidate within a few days.

Further security releases of Python 2.5 will be made until September 2011.

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] 3to2 0.1 alpha 1 released

[Martin v. Löwis]

> I have released the first alpha version of 3to2 after finishing it for
> my Google Summer of Code 2009(tm) project.

Congratulations! I understand SoC is basically over, but I would still
like to request two things:

- can you please register it with PyPI?
- can you please announce/report some plans for the future of this
  project? In particular, will you continue to work on it?

Thanks,
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] PEP 3144: IP Address Manipulation Library for the Python Standard Library

[skip]

Martin> I think it's too early to tell. It may be that they have not yet
Martin> achieved their purpose - just let's wait fifty more years (and
Martin> I'm only half-joking).

So what you're really saying is we only have to wait 25 years...

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] 3to2 0.1 alpha 1 released

[Joe Amenta]

On Wed, Aug 26, 2009 at 4:26 PM, "Martin v. Löwis" wrote:

> > I have released the first alpha version of 3to2 after finishing it for
> > my Google Summer of Code 2009(tm) project.
>
> Congratulations! I understand SoC is basically over, but I would still
> like to request two things:
>
> - can you please register it with PyPI?
> - can you please announce/report some plans for the future of this
>  project? In particular, will you continue to work on it?
>
> Thanks,
> Martin


-- 3to2 is now registered with
PyPI.
Did I do it right?
-- I plan to continue to work on 3to2 in my free time, though I have one of
those social lives, so I could certainly use some help; in particular, I
could use some quality bug
reports.
My long-term plans for the future are:

   - Bugfixes
   - Keep up with new features added in newer versions of py3k
   - Ensure syntactical correctness with a more robust test suite

My short-term plans for the future are:

   - Fixes imports and imports2 need to work properly
   - Continue to build a suitable test suite that tests common cases of all
   fixers
   - print fixer refactors the syntax into print statements rather than
   imports print_function from __future__

Thanks for the acknowledgement,
--Joe
___
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] Excluding the current path from module search path?

[Chris Withers]

Nick Coghlan wrote:

The details of the sys.path manipulation at program startup are
documented here:
http://docs.python.org/using/cmdline.html#command-line

The directory prepended to sys.path is based on the code executed by the
command line.


It's more subtle than that though...

The OP in http://bugs.python.org/issue1734860 is being bitten by the 
same expectation that I am: sitecustomize.py should be found somewhere 
on the sys.path present at the start of the script/module/command/etc 
being executed. (The bug referenced in that report makes things worse, 
because this used to work, at least on Windows ;-) )


The problem is that site.py (and therefore sitecustomize.py) is imported 
early in main.c on line 516 as part of Py_Initialize(), but the path of 
the current script only gets added later on in RunMainFromImporter 
called on line 569.


Strictly speaking, the docs at http://docs.python.org/library/site.html 
aren't lying, but it takes an understanding of when site.py is imported 
that isn't available to anyone who doesn't read C to know why a path 
that is present on sys.path when the user's script starts isn't being 
searched for sitecustomize.py


What do people feel about this?

At the very least, I'd like to add a warning box in site.html to explain 
why sitecustomize might not be found where people expect.


I'd *like* to have the paths be the same for site.py as they are for the 
subsequent code that's executed, but would that make too much of a mess 
of main.c and runpython.c?


cheers,

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
   - http://www.simplistix.co.uk
___
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 3144: IP Address Manipulation Library for the Python Standard Library

[DrKJam]

I've started a very basic (work in progress) entry on the netaddr wiki to
track various aspects of this discussion that might not be in a format
suitable for publishing to the list or are too lengthy. It will also allow
my ascii art diagrams to render correctly ;-)

http://code.google.com/p/netaddr/wiki/PEP3144

I will be updating it as free time become available to me over the coming
days. Feel free to make comments on the wiki page itself if you want me to
make any changes. Duncan McGreggor should be able to make changes if I am
not available for whatever reason :-

If anyone has suggestions for a better place to put this, please shout (but
not too loudly please Peter M. ;-)

Thanks,

Dave M.

PS - Can't wait for Google Wave which would make this kind of thing so much
easier ;-)
___
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] deleting setdefaultencoding iin site.py is evil

[Chris Withers]

exar...@twistedmatrix.com wrote:
The ability to change the default encoding is a misfeature.  There's 
essentially no way to write correct Python code in the presence of this 
feature.


How so? If every single piece of text in your project is encoded in a 
superset of ascii (such as utf-8), why would this be a problem?
Even if you were evil/stupid and mixed encodings, surely all you'd get 
is different unicode errors or mayvbe the odd strange character during 
display?


It may be a major task, but the best thing you can do is find each str 
and unicode operation in the software you're working with and make them 
correct with respect to your inputs and outputs.  Flipping a giant 
switch for the entire process is just going to change which things are 
wrong.


Well, flipping that giant switch has worked in production for the past 5 
years, so I'm afraid I'll respectfully disagree. I'd suspect the 
pragmatics of real world software are with that function even exists, 
and it's extremely useful when used correctly...


Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
   - http://www.simplistix.co.uk
___
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] deleting setdefaultencoding iin site.py is evil

[Chris Withers]

M.-A. Lemburg wrote:

Let's look at this from another angle: sys.setdefaultencoding()
is only made available for use in site.py. 


...see this:

http://mail.python.org/pipermail/python-dev/2009-August/091391.html

I would like to use sitecustomize.py for all the very good reasons given 
in this thread:


- I don't want to change the default encoding for every project that 
uses the python installation in question


- I don't even want to change the default encoding for every python 
script run by the current user


- I only want to change the default encoding for one particular project.

Sadly, for the reasons I describe in the thread, site.py won't find a 
sitecustomize.py in this situation...


If you use it anywhere else, you're on your own. 


No problem with that. To be specific, this is a Zope 2.12 instance 
driven by this buildout:


[instance]
recipe = zc.recipe.egg
eggs = ${buildout:eggs}
interpreter = py
entry-points=
   runzope=Zope2.Startup.run:run
   zopectl=Zope2.Startup.zopectl:main
scripts = runzope zopectl
initialization =
   import sys
   reload(sys)
   sys.setdefaultencoding('utf-8')
   sys.argv[1:1] = ['-C','${buildout:directory}/etc/instance.conf']

The call to sys.setdefaultencoding is *very* early in the scheme of 
things... The runzope script that gets run only has some sys.path 
manipulation before sys.setdefaultencoding gets called. What problems 
could there be by calling sys.setdefaultencoding there?



Such usage
is not supported and may very well break your interpreter 


Can you give an example?


or
cause data corruption (the default encoded versions of Unicode
objects are cached inside the objects).


When called as early as in the above script, what objects would have 
encoded strings cached in them?



Now, in your particular case, you're probably better off just
tweaking site.py directly in your custom Python interpreter
rather than relying on sitecustomize.py (see setencoding() in
site.py).


Why?

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
   - http://www.simplistix.co.uk
___
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] deleting setdefaultencoding iin site.py is evil

[Chris Withers]

Guido van Rossum wrote:

In retrospect, it should have been called sys._setdefaultencoding().
That sends an extra signal that it's not meant for general use.


Crazy idea: how about mutating it into sys._setdefaultencoding rather 
than deleting it?


Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
   - http://www.simplistix.co.uk
___
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] Problems with events in a numeric keyboard

[Greg Ewing]

Martin Zugnoni wrote:

when I press
the triple zero key once, I receive three events from the single zero key.
I need to make a disctintion between these keys


Sounds like you can't, except perhaps by detecting
three '0' key events arriving at almost the same
time.

--
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] deleting setdefaultencoding iin site.py is evil

[Martin v. Löwis]

>> The ability to change the default encoding is a misfeature.  There's
>> essentially no way to write correct Python code in the presence of
>> this feature.
> 
> How so? If every single piece of text in your project is encoded in a
> superset of ascii (such as utf-8), why would this be a problem?

What is "every single piece of text"? Every string occurring in source
code? or also every single string that may be read from a file, a
socket, out of a database, or from a user interface?

How can you be certain that any string is UTF-8 when doing any
reasonable IO?

> Even if you were evil/stupid and mixed encodings, surely all you'd get
> is different unicode errors or mayvbe the odd strange character during
> display?

One specific problem is dictionaries will stop working correctly if you
set the default encoding to anything but ASCII. The reason is that
with UTF-8 as the default encoding, you get

py> u"\u20ac" == u"\u20ac".encode("utf-8")
True
py> hash(u"\u20ac") == hash(u"\u20ac".encode("utf-8"))
False

So objects that compare equal will not hash equal. As a consequence, you
may have two different values for what should be the same key in a
dictionary.

> Well, flipping that giant switch has worked in production for the past 5
> years, so I'm afraid I'll respectfully disagree. I'd suspect the
> pragmatics of real world software are with that function even exists,
> and it's extremely useful when used correctly...

It has worked in your application. See my example above: it is very easy
to create applications that stop working correctly if you use
setdefaultencoding (at all - the only supported value is "latin-1",
since Unicode strings hash the same as byte strings if all characters
are in row 0).

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] deleting setdefaultencoding iin site.py is evil

[Martin v. Löwis]

>> In retrospect, it should have been called sys._setdefaultencoding().
>> That sends an extra signal that it's not meant for general use.
> 
> Crazy idea: how about mutating it into sys._setdefaultencoding rather
> than deleting it?

Please don't post crazy ideas unless you really mean them.

This specific crazy idea must be rejected; it would break backwards
compatibility, for no good reason.

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