Re: [Python-Dev] Breaking undocumented API

[Michael Foord]

On 10/11/2010 15:48, R. David Murray wrote:

On Wed, 10 Nov 2010 13:12:09 +0900, "Stephen J. Turnbull"  
wrote:

Nick Coghlan writes:

  >  >  Module writers who compound the error by expecting to be imported
  >  >  this way, thereby bogarting the global namespace for their own
  >  >  purposes, should be fish-slapped. ;)
  >
  >  Be prepared to fish-slap all of python-dev then - we use precisely
  >  this technique to support optional acceleration modules. The pure
  >  Python versions of pairs like profile/_profile and heapq/_heapq
  >  include a try/except block at the end that does the equivalent of:
  >
  >try:
  >  from _accelerated import * # Allow accelerated overrides
  >except ImportError:
  >  pass # Use pure Python versions

But these identifiers will appear at the module level, not global, no?
Otherwise this technique couldn't be used.  I don't really understand
what Tres is talking about when he writes "modules that expect to be
imported this way".  The *imported* module shouldn't care, no?  This
is an issue for the *importing* code to deal with.

I think Tres was referring to certain packages (which shall remain
nameless since I don't feel like googling to find one) whose
documentation recommends the 'from  import *' methodology.


Contenders include popular libraries like fabric and django:

http://docs.fabfile.org/0.9.2/usage/fabfiles.html
http://docs.djangoproject.com/en/1.2/intro/tutorial03/

All the best,

Michael


At least that's how I read "Module writers who..."  (that is, he's not
saying the *module* expects to be imported that way). [*]

--
R. David Murray  www.bitdance.com

[*] although reading that sentence literally, the thought of such a
module writer themselves being imported that way (a la Tron) has a
certain charm
___
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.voidspace.org.uk/

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.

___
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] Breaking undocumented API

[Michael Foord]

On 11/11/2010 05:41, Alexander Belopolsky wrote:

On Wed, Nov 10, 2010 at 6:10 PM, Ron Adam  wrote:
..

On Nov 10, 2010, at 5:47 AM, Michael Foord wrote:

So it is obvious that we don't have a clearly stated policy for what
defines the public API of standard library modules.

How about making this explicit (either pep 8 or our developer docs):

..

The way I read Guido's email is that it is a situation dependent judgment
call for those cases that aren't clear.

I think what Micheal is trying to say is for us to agree on some things so
we can go forward with a little more clarity.

I don't understand why everyone seem to have accepted Michael's
premise that "we don't have a clearly stated policy for what defines
the public API of standard library modules."  We do have such a policy
and it is well known (while the location in the reference manual may
not be):


Ha. 14 paragraphs into the grammar reference on the import statement is 
perhaps not where developers would go to look for Python standard 
library development policy (and it *isn't* where they should go - 
standard library policy should be in pep 8 or our developer docs).


What you're saying is that the behaviour of "import *" *already* defines 
the public API at module level (but says nothing about class members or 
modules whose names begin with a leading underscore - those rules follow 
as a natural extension though).


By "clearly stated", I meant part of the python development 
documentation and / or standard library documentation. This is so that 
both users and developers are clear about the rules, and we have 
somewhere obvious to point people to. From this discussion it is clear 
that developers *don't* have a common understanding about what defines 
the public API of a standard library module. Suggestions as to what the 
rule is have included "only documented APIs are public" and "every 
member with a docstring is public"...


This largely comes from the heritage of the standard library which, as 
you point out, pre-dates the addition of __all__ / import * behaviour to 
the language. However many newer modules don't define __all__ either and 
several core developers have said they don't consider it a requirement 
that they do (as __all__ is a maintenance burden).



"""
The public names defined by a module are determined by checking the
module’s namespace for a variable named __all__;
if defined, it must
be a sequence of strings which are names defined or imported by that
module. The names given in __all__ are all considered public and are
required to exist. If __all__ is not defined, the set of public names
includes all names found in the module’s namespace which do not begin
with an underscore character ('_'). __all__ should contain the entire
public API. It is intended to avoid accidentally exporting items that
are not part of the API (such as library modules which were imported
and used within the module).
"""  --

The question that I had when I started this thread was not about a
definition of "public API."  It was about a policy with respect to
modules that precede the introduction of __all__ and the modern
definition of public names.  (See r18692 "Two changes to
from...import", and r23920 ' adding a definition of "public names"'.)



Well - restated your question is asking if adding a __all__ *changes* 
the public API of a standard library module. If it does then it is has 
stronger backwards compatibility implications than if it doesn't.


So given a standard library module that doesn't define __all__, what is 
considered the public API?



Is it OK to add __all__ to such modules that does not include all
names not starting with an underscore?  Is it OK to then remove names
that clearly were not intended to be public?


Given the rules I suggested, which are basically the same as the one 
*you* are saying are already in place, if "import *" exports these names 
then you shouldn't change that behaviour without going through the 
deprecation process.


It would be clearer if these rules were stated either in pep 8 or our 
developer documentation of course.


All the best,

Michael


Case in point: trace.rx_blank.  See also.
___
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.voidspace.org.uk/

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without pre

Re: [Python-Dev] Breaking undocumented API

[Karen Tracey]

On Thu, Nov 11, 2010 at 6:51 AM, Michael Foord wrote:

> On 10/11/2010 15:48, R. David Murray wrote:
>
>> I think Tres was referring to certain packages (which shall remain
>> nameless since I don't feel like googling to find one) whose
>> documentation recommends the 'from  import *' methodology.
>>
>
> Contenders include popular libraries like fabric and django:
>
> http://docs.fabfile.org/0.9.2/usage/fabfiles.html
> http://docs.djangoproject.com/en/1.2/intro/tutorial03/
>
>
That is one very specific module in Django that gets imported that way, it
is not a general pattern recommended by Django. For every other Django
module besides that one you will see specific imports being used in the doc.

Karen
___
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] Breaking undocumented API

[Alexander Belopolsky]

On Thu, Nov 11, 2010 at 7:01 AM, Michael Foord
 wrote:
..
>> Is it OK to add __all__ to such modules that does not include all
>> names not starting with an underscore?  Is it OK to then remove names
>> that clearly were not intended to be public?
>
> Given the rules I suggested, which are basically the same as the one *you*
> are saying are already in place, if "import *" exports these names then you
> shouldn't change that behaviour without going through the deprecation
> process.

I don't dispute that these are *the* rules, but my question was
whether it is ok to break them in specific cases such as
trace.rx_blank.  If not, how can we deprecate trace.rx_blank which is
a regex constant?

Another specific case is token.main.  See .
___
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] Breaking undocumented API

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/11/2010 08:23 AM, Alexander Belopolsky wrote:
> On Thu, Nov 11, 2010 at 7:01 AM, Michael Foord
>  wrote:
> ..
>>> Is it OK to add __all__ to such modules that does not include all
>>> names not starting with an underscore?  Is it OK to then remove names
>>> that clearly were not intended to be public?
>>
>> Given the rules I suggested, which are basically the same as the one *you*
>> are saying are already in place, if "import *" exports these names then you
>> shouldn't change that behaviour without going through the deprecation
>> process.
> 
> I don't dispute that these are *the* rules, but my question was
> whether it is ok to break them in specific cases such as
> trace.rx_blank.  If not, how can we deprecate trace.rx_blank which is
> a regex constant?
> 
> Another specific case is token.main.  See .

I would argue that the narrative documentation for the module is
normative for defining "public API", trumping even a pre-existing
'__all__'.  Given that all non-private stdlib modules have such docs,
nobody should be relying on '__all__' as anything other than a convenience.

Therefore, in the absence of an '__all__', adding one which conforms to
the docs should not require deprecations, as the set of applications /
modules which both use the undocumented names *and* do so via 'import *'
can be safely deemed "too small to worry about".


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzb8ioACgkQ+gerLs4ltQ4WBwCgux91ooO8lega+HRlYClSDj/B
SdwAoIq3ZjMwEL1V7vX8sq9k/xSRhIjA
=v9Zc
-END PGP SIGNATURE-

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Breaking undocumented API

[Fred Drake]

On Thu, Nov 11, 2010 at 8:23 AM, Alexander Belopolsky
 wrote:
> I don't dispute that these are *the* rules, but my question was
> whether it is ok to break them in specific cases such as
> trace.rx_blank.  If not, how can we deprecate trace.rx_blank which is
> a regex constant?

Since trace is documented and rx_blank isn't covered, I think it's
pretty clear it was never intended as API.  I'd be fine with changing
the visibility of rx_blank, and see no need to change its name.

> Another specific case is token.main.  See .

Yep.  Again, it's clear that it's not API, and that's a documented module.


  -Fred

--
Fred L. Drake, Jr.    
"A storm broke loose in my mind."  --Albert Einstein
___
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] Breaking undocumented API

[Alexander Belopolsky]

On Thu, Nov 11, 2010 at 8:43 AM, Fred Drake  wrote:
..
> Since trace is documented and rx_blank isn't covered, I think it's
> pretty clear it was never intended as API.  I'd be fine with changing
> the visibility of rx_blank, and see no need to change its name.

While I obviously agree with your conclusion, your logic is not
perfect because trace documentation is *much* younger than the module.
 How would you apply your reasoning to trace.find_strings()?  It is
undocumented, its name is misleading, but it is used in the wild
according to google code search.  I draw the line somewhere between
trace.rx_blank and trace.find_strings.
___
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] Breaking undocumented API

[Michael Foord]

On 11/11/2010 13:39, Tres Seaver wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/11/2010 08:23 AM, Alexander Belopolsky wrote:

On Thu, Nov 11, 2010 at 7:01 AM, Michael Foord
  wrote:
..

Is it OK to add __all__ to such modules that does not include all
names not starting with an underscore?  Is it OK to then remove names
that clearly were not intended to be public?

Given the rules I suggested, which are basically the same as the one *you*
are saying are already in place, if "import *" exports these names then you
shouldn't change that behaviour without going through the deprecation
process.

I don't dispute that these are *the* rules, but my question was
whether it is ok to break them in specific cases such as
trace.rx_blank.  If not, how can we deprecate trace.rx_blank which is
a regex constant?

Another specific case is token.main.  See.

I would argue that the narrative documentation for the module is
normative for defining "public API", trumping even a pre-existing
'__all__'.  Given that all non-private stdlib modules have such docs,
nobody should be relying on '__all__' as anything other than a convenience.

Therefore, in the absence of an '__all__', adding one which conforms to
the docs should not require deprecations, as the set of applications /
modules which both use the undocumented names *and* do so via 'import *'
can be safely deemed "too small to worry about".


I don't think this is generally sufficient given the not-infrequent 
occurrence of undocumented-but-used APIs in the standard library.


Another example is re.Scanner.

http://bugs.python.org/issue5337

Making the rules explicit and following a deprecation process seems like 
a sensible way forward to me. That still leaves Alexander's question 
open; how to handle module level constants that can't easily be formally 
deprecated. One possibility is using something similar to the twisted 
technique for deprecating module constants. That would mean adding code 
to the standard library to do this.


I would say that if it seems unlikely that the constants are used in the 
wild, and google code search confirms this, then it is fine to skip the 
deprecation process. If there are known uses we should at least document 
the deprecation (and alias) for a release before removing.


All the best,

Michael




Tres.
- -- 
===

Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzb8ioACgkQ+gerLs4ltQ4WBwCgux91ooO8lega+HRlYClSDj/B
SdwAoIq3ZjMwEL1V7vX8sq9k/xSRhIjA
=v9Zc
-END PGP SIGNATURE-

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk



--

http://www.voidspace.org.uk/

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.

___
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] Breaking undocumented API

[Michael Foord]

On 11/11/2010 13:51, Alexander Belopolsky wrote:

On Thu, Nov 11, 2010 at 8:43 AM, Fred Drake  wrote:
..

Since trace is documented and rx_blank isn't covered, I think it's
pretty clear it was never intended as API.  I'd be fine with changing
the visibility of rx_blank, and see no need to change its name.

While I obviously agree with your conclusion, your logic is not
perfect because trace documentation is *much* younger than the module.
  How would you apply your reasoning to trace.find_strings()?  It is
undocumented, its name is misleading, but it is used in the wild
according to google code search.  I draw the line somewhere between
trace.rx_blank and trace.find_strings.
I agree. Known / likely usage has to be the determining factor for 
poorly named but undocumented members.


For functions though formal deprecation is easy - so it should only be 
an *issue* for constants. (And there the issue is not whether we can 
remove but how we do it.)


Michael

--

http://www.voidspace.org.uk/

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.

___
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] Breaking undocumented API

[Nick Coghlan]

On Thu, Nov 11, 2010 at 11:39 PM, Tres Seaver  wrote:
> I would argue that the narrative documentation for the module is
> normative for defining "public API", trumping even a pre-existing
> '__all__'.  Given that all non-private stdlib modules have such docs,
> nobody should be relying on '__all__' as anything other than a convenience.
>
> Therefore, in the absence of an '__all__', adding one which conforms to
> the docs should not require deprecations, as the set of applications /
> modules which both use the undocumented names *and* do so via 'import *'
> can be safely deemed "too small to worry about".

Except, as noted earlier in the thread, many Python programmers (and I
count myself amongst this group) often use dir() and help() to find
out what a module has available, and only resort to the written
documentation if we get stuck.

My personal opinion is that we should be trying to get the standard
library to the point where __all__ definitions are unnecessary - if a
name isn't in __all__, it should start with an underscore (and if that
is true, then the __all__ definition becomes effectively redundant).

That way, all sources of information (docs, dir(), help(), import *)
give the same answer as to what constitutes the public API.

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] Breaking undocumented API

[Łukasz Langa]

Am 08.11.2010 23:07, schrieb Raymond Hettinger:
Some sense needs to be applied to the decision. Google's code search 
is great for showing how people actually have used a module in real 
world code. If that shows that people are accessing and/or changing an 
attribute, it probably needs to remain exposed. In the absence of a 
code search, good guesses can be made about what someone might 
reasonably and usefully be accessing (i.e. glob0 isn't likely).


Danger, Will Robinson!

I just tried to use that to determine if I could consider moving a 
module-wide constant in configparser to the parser instance (to enable 
customization).


Search on code.google.com returned me four incompatible result sets 
within 30 minutes. One had only two entries whereas another had 7 pages 
of results.


Search using www.google.com/codesearch found 3 pages of results 
different than the search on Google Code. The best part is that 
codesearch found some occurences on Google Code which Google Code's own 
search didn't.


None of them returned sourceforge.net results whereas search on 
Koders.com found occurences only on SourceForge.


The idea to use a code search engine is ingenious but the current tools 
are not yet reliable enough for the task.



For example, when the pprint rewrite is finally ready, if there is an 
incompatible API change, I expect that a new clean class will be offered, but 
that the old will be left in-place so that tons of existing code won't break).

Unrelated but that's the way I'm doing it.
___
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] Breaking undocumented API

[Barry Warsaw]

On Nov 11, 2010, at 12:41 AM, Alexander Belopolsky wrote:

>Is it OK to add __all__ to such modules that does not include all
>names not starting with an underscore?  Is it OK to then remove names
>that clearly were not intended to be public?

I would say in general, yes.  It's a good small modernization and stdlib
improvement.  However, this shouldn't be done as a bug fix to a stable
release, and care must be taken to consider backward compatibility.  IOW, if
you really think it's a name that is not used publicly, or is usually only
imported explicitly, then I think it's fine leaving it out of __all__.  It's
not a difficult change to work around.

-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] Breaking undocumented API

[Barry Warsaw]

On Nov 12, 2010, at 12:02 AM, Nick Coghlan wrote:

>My personal opinion is that we should be trying to get the standard
>library to the point where __all__ definitions are unnecessary - if a
>name isn't in __all__, it should start with an underscore (and if that
>is true, then the __all__ definition becomes effectively redundant).

Agreed, though I wouldn't *remove* __all__'s, I would establish a convention
where they can be generated programmatically.  Keeping __all__ in sync with
the code is a PITA.  It screams for automation.

-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] Breaking undocumented API

[Łukasz Langa]

Am 11.11.2010 16:05, schrieb Barry Warsaw:
Agreed, though I wouldn't *remove* __all__'s, I would establish a 
convention

where they can be generated programmatically.  Keeping __all__ in sync with
the code is a PITA.  It screams for automation.


You mean runtime automation, e.g. creating __all__ on the fly omitting 
underscored names?


--
Best regards,
Łukasz Langa
___
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] Breaking undocumented API

[Michael Foord]

On 11/11/2010 15:17, Łukasz Langa wrote:

Am 11.11.2010 16:05, schrieb Barry Warsaw:
Agreed, though I wouldn't *remove* __all__'s, I would establish a 
convention
where they can be generated programmatically.  Keeping __all__ in 
sync with

the code is a PITA.  It screams for automation.


You mean runtime automation, e.g. creating __all__ on the fly omitting 
underscored names?


Writing code to generate a __all__ that duplicates the default behaviour 
seems redundant to me.


Michael

--

http://www.voidspace.org.uk/

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.

___
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] Breaking undocumented API

[Antoine Pitrou]

On Thu, 11 Nov 2010 15:18:40 +
Michael Foord  wrote:
> On 11/11/2010 15:17, Łukasz Langa wrote:
> > Am 11.11.2010 16:05, schrieb Barry Warsaw:
> >> Agreed, though I wouldn't *remove* __all__'s, I would establish a 
> >> convention
> >> where they can be generated programmatically.  Keeping __all__ in 
> >> sync with
> >> the code is a PITA.  It screams for automation.
> >
> > You mean runtime automation, e.g. creating __all__ on the fly omitting 
> > underscored names?
> >
> Writing code to generate a __all__ that duplicates the default behaviour 
> seems redundant to me.

Agreed with Michael.  __all__ is useful mostly when you don't adhere to
the convention that private APIs should have a leading underscore.

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

[Python-Dev] Removal of Win32 ANSI API

[Hirokazu Yamamoto]

Hello. Is it possible to remove Win32 ANSI API (ie: GetFileAttributesA)
and only use Win32 WIDE API (ie: GetFileAttributesW)?
Mainly in posixmodule.c.
I think we can simplify the code hugely. (This means droping bytes
support for os.stat etc on windows)

# I recently did it for winsound.PlaySound with MvL's approval

Thank you.
___
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] Removal of Win32 ANSI API

[Tim Golden]

On 11/11/2010 16:07, Hirokazu Yamamoto wrote:

Hello. Is it possible to remove Win32 ANSI API (ie: GetFileAttributesA)
and only use Win32 WIDE API (ie: GetFileAttributesW)?
Mainly in posixmodule.c.
I think we can simplify the code hugely. (This means droping bytes
support for os.stat etc on windows)

# I recently did it for winsound.PlaySound with MvL's approval


+1 from me

TJG
___
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] Removal of Win32 ANSI API

[Ulrich Eckhardt]

On Thursday 11 November 2010, Hirokazu Yamamoto wrote:
> Is it possible to remove Win32 ANSI API (ie: GetFileAttributesA)
> and only use Win32 WIDE API (ie: GetFileAttributesW)?
> Mainly in posixmodule.c.
> I think we can simplify the code hugely.

+1

MS Windows variants that only support the ANSI API (win9x) are officially 
unsupported since 2.5 or 2.6. Further, this also eases porting to MS Windows 
CE, which I'd still like to to see one day.

> (This means droping bytes support for os.stat etc on windows)

I disagree that not using the ANSI win32 API means dropping byte support for 
os.stat. I'd rather say that it means converting bytes at the earliest 
possible time and only using unicode internally. But I'm guessing a bit here, 
I haven't looked at the code for a while.

> # I recently did it for winsound.PlaySound with MvL's approval

Interesting, is there a ticket associate with this? Also, was that on Python 3 
or 2? Which commits?

Uli

-- 
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

**
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
   Visit our website at 
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

___
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] Removal of Win32 ANSI API

[Antoine Pitrou]

On Thu, 11 Nov 2010 16:10:35 +
Tim Golden  wrote:
> On 11/11/2010 16:07, Hirokazu Yamamoto wrote:
> > Hello. Is it possible to remove Win32 ANSI API (ie: GetFileAttributesA)
> > and only use Win32 WIDE API (ie: GetFileAttributesW)?
> > Mainly in posixmodule.c.
> > I think we can simplify the code hugely. (This means droping bytes
> > support for os.stat etc on windows)
> >
> > # I recently did it for winsound.PlaySound with MvL's approval
> 
> +1 from me

How do you support cross-platform code using bytes filenames?
IIRC, it has already been argued that it was an important feature. Many
filesystem-related utilities might prefer to handle filenames in bytes
form.

("winsound" is a Windows-specific module so that wasn't a concern
obviously)

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] [Python-checkins] r86348 - in python/branches/py3k/Lib: test/test_xml_etree.py xml/etree/ElementTree.py

[Éric Araujo]

>> Shouldn’t this include an entry in NEWS and maybe in ACKS?
> It was a very simple bug fix (caused due to an overlook initially), so
> did not add NEWS/ACKS. For features, larger fixes or complete patches,
> I the add NEWS and ACKS as appropriate.

Thanks for the reply.  Now I’m unsure about the rules for adding NEWS
entries: some bugs are important but have a very simple fix (see
#1718574 for an example).  I guess I’ll just always add an entry :)

Brett, maybe this is something to cover in the dev docs.

make-patchcheck-ly yours

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] r86348 - in python/branches/py3k/Lib: test/test_xml_etree.py xml/etree/ElementTree.py

[Brett Cannon]

On Thu, Nov 11, 2010 at 09:38, Éric Araujo  wrote:
>>> Shouldn’t this include an entry in NEWS and maybe in ACKS?
>> It was a very simple bug fix (caused due to an overlook initially), so
>> did not add NEWS/ACKS. For features, larger fixes or complete patches,
>> I the add NEWS and ACKS as appropriate.
>
> Thanks for the reply.  Now I’m unsure about the rules for adding NEWS
> entries: some bugs are important but have a very simple fix (see
> #1718574 for an example).  I guess I’ll just always add an entry :)
>
> Brett, maybe this is something to cover in the dev docs.

I just follow Guido's own personal rule: if the fix required thought
they should go into Misc/ACKS.
___
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] Breaking undocumented API

[Alexander Belopolsky]

2010/11/11 Michael Foord :
..
>> You mean runtime automation, e.g. creating __all__ on the fly omitting
>> underscored names?
>>
> Writing code to generate a __all__ that duplicates the default behaviour
> seems redundant to me.
>

FWIW, I like having __all__ at the top of the module.  It feels like a
table of contents at the start of a chapter.  In some cases it may
also serve as an optimization when len(__all__) is much smaller than
len(__dict__).  I also don't like _ prefix to become an exclusive
means to express privateness.

I think the current definition of "public names" is a good one and
just needs to be made more visible in the docs.  If the module defines
__all__, that should be the ultimate answer to what is public in that
module.   (Users should learn to use help(module) instead of
dir(module) for API discovery.)   If __all__ is not defined in the
module, I think it is good to introduce it after a careful review of
what it should contain.  And __all__ should never contain names that
start with _.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] r86348 - in python/branches/py3k/Lib: test/test_xml_etree.py xml/etree/ElementTree.py

[Éric Araujo]

> I just follow Guido's own personal rule: if the fix required thought
> they should go into Misc/ACKS.

Okay.  Same rule for NEWS?

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] r86348 - in python/branches/py3k/Lib: test/test_xml_etree.py xml/etree/ElementTree.py

[Brett Cannon]

On Thu, Nov 11, 2010 at 10:10, Éric Araujo  wrote:
>> I just follow Guido's own personal rule: if the fix required thought
>> they should go into Misc/ACKS.
>
> Okay.  Same rule for NEWS?
>
>

I do a NEWS entry if a bug was fixed or semantics changed/added for
anything public (e.g., I don't do an entry for every little
clarification in the docs or new tests fixed or written).
___
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] Breaking undocumented API

[Steven D'Aprano]

Nick Coghlan wrote:


My personal opinion is that we should be trying to get the standard
library to the point where __all__ definitions are unnecessary - if a
name isn't in __all__, it should start with an underscore (and if that
is true, then the __all__ definition becomes effectively redundant).


You don't *need* to define __all__ -- if you don't, import * will import 
everything that doesn't start with a leading underscore. __all__ is only 
useful when you want more control over what is or isn't imported. If you 
don't need that control, just don't define __all__, and the problem is 
solved.




That way, all sources of information (docs, dir(), help(), import *)
give the same answer as to what constitutes the public API.



I disagree with the underlying assumption that import * need necessarily 
import the entire public API. That's not how I use it in my modules, and 
the option should be available to std library modules as well.


When I create a module, I distinguish between three categories of functions:

* private, which start with an underscore;
* the core public API, which is listed in __all__; and
* support/helper functions, which are not part of the core functionality 
of the module but are public.


If you import * you will get just the core functions. If you want the 
support functions, you need to use the fully qualified module.name, or 
otherwise import them yourself.


This division of public functions into first and second class API 
functions is a deliberate design choice on my part. I expect the core 
functionality to be fully documented. Helper and support functions may 
not be -- there should be some docs, but doing so is a lower priority.


The support functions are public, and available for use, if you go 
looking for them, but I neither encourage nor discourage users from 
doing so.


I don't see any reason that the standard library should not be permitted 
to use the same convention.



Another couple of objections to getting rid of __all__:

If you're proxying modules or built-ins, you may not be able to use a 
_private name, but you may not want import * to pick up your proxies.


I find it annoying to see this:

import module as _module
_module.func()

(instead of import module and merely leaving module out of __all__)

I accept that some standard library authors may choose this convention, 
but I don't want to see it become mandatory.




--
Steven
___
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] Breaking undocumented API

[Alexander Belopolsky]

On Thu, Nov 11, 2010 at 7:01 AM, Michael Foord
 wrote:
..
>> I don't understand why everyone seem to have accepted Michael's
>> premise that "we don't have a clearly stated policy for what defines
>> the public API of standard library modules."  We do have such a policy
>> and it is well known (while the location in the reference manual may
>> not be):
>
> Ha. 14 paragraphs into the grammar reference on the import statement is
> perhaps not where developers would go to look for Python standard library
> development policy..

Very true.  To make it slightly more visible, any objections to the
following patch? (It adds "public names (in module globals)" linking
to that 14-th paragraph in the index.)

Index: Doc/reference/simple_stmts.rst
===
--- Doc/reference/simple_stmts.rst  (revision 86409)
+++ Doc/reference/simple_stmts.rst  (working copy)
@@ -794,6 +794,7 @@
 namespace of the :keyword:`import` statement..

 .. index:: single: __all__ (optional module attribute)
+.. index:: public names (in module globals)

 The *public names* defined by a module are determined by checking the module's
 namespace for a variable named ``__all__``; if defined, it must be a
sequence of
___
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] Breaking undocumented API

[Antoine Pitrou]

On Thu, 11 Nov 2010 13:40:36 -0500
Alexander Belopolsky  wrote:
> On Thu, Nov 11, 2010 at 7:01 AM, Michael Foord
>  wrote:
> ..
> >> I don't understand why everyone seem to have accepted Michael's
> >> premise that "we don't have a clearly stated policy for what defines
> >> the public API of standard library modules."  We do have such a policy
> >> and it is well known (while the location in the reference manual may
> >> not be):
> >
> > Ha. 14 paragraphs into the grammar reference on the import statement is
> > perhaps not where developers would go to look for Python standard library
> > development policy..
> 
> Very true.  To make it slightly more visible, any objections to the
> following patch? (It adds "public names (in module globals)" linking
> to that 14-th paragraph in the index.)

I think what Michael meant is that the language grammar reference is not
(and shouldn't be) the authority on stdlib development policy. To which
I would agree.

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] Removal of Win32 ANSI API

[Victor Stinner]

On Thursday 11 November 2010 17:07:28 Hirokazu Yamamoto wrote:
> Hello. Is it possible to remove Win32 ANSI API (ie: GetFileAttributesA)
> and only use Win32 WIDE API (ie: GetFileAttributesW)?
> Mainly in posixmodule.c.

Even if I hate the MBCS encoding, because it replaces undecodable characters 
by similar glyphs by default, I'm not certain that it is a good idea to drop 
the bytes API. Can it be a problem to port programs from Python2 to Python3? 
Do major Python2 programs/libraries rely on the bytes API?

> I think we can simplify the code hugely. (This means droping bytes
> support for os.stat etc on windows)

Sure, it will divide the number of lines, of the code specific to Windows, by 
two.

Victor
___
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] Removal of Win32 ANSI API

[Martin v. Löwis]

> How do you support cross-platform code using bytes filenames?
> IIRC, it has already been argued that it was an important feature. Many
> filesystem-related utilities might prefer to handle filenames in bytes
> form.

It would be a policy decision. However, I think it is hear-say that
filesystem-related utilities might prefer byte file names. On Windows,
some files are inaccessible if you constrain yourself to byte filenames,
so once people learn about this limitation, I expect them to switch to
Unicode filenames on Windows - for the same reason they use byte
filenames on Unix (i.e. to be able to access all files correctly).

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] Removal of Win32 ANSI API

[Martin v. Löwis]

> Even if I hate the MBCS encoding, because it replaces undecodable characters 
> by similar glyphs by default, I'm not certain that it is a good idea to drop 
> the bytes API. Can it be a problem to port programs from Python2 to Python3? 
> Do major Python2 programs/libraries rely on the bytes API?

I don't actually know for a fact, but I expect that the answer is "no".

The questions is: where do file names typically come from? My guess
is that they come from
a) hard-coded strings in the source code
b) command line arguments/environment variables
c) directory listings
[of course, there are other ways, like GUI input, getcwd(), etc]

In case a), you have filenames such as ".", e.g. as a parameter to
listdir or walk. These will typically be regular strings in Python 2,
which become Unicode strings in 3. You would actively need to put b""
prefixes into the code.

In case b), they will be Unicode strings in Python 3.

In case c), they will be Unicode strings if the argument is a Unicode
string. So by induction, file names will be typically unicode. The
exception will be libraries/applications which make deliberate attempts
to get byte-oriented file names.

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] Removal of Win32 ANSI API

[Antoine Pitrou]

On Thu, 11 Nov 2010 20:44:52 +0100
"Martin v. Löwis"  wrote:
> > How do you support cross-platform code using bytes filenames?
> > IIRC, it has already been argued that it was an important feature. Many
> > filesystem-related utilities might prefer to handle filenames in bytes
> > form.
> 
> It would be a policy decision. However, I think it is hear-say that
> filesystem-related utilities might prefer byte file names.

One possible situation is when you receive filenames in bytes form from
an external API or tool (or even the contents of a file). If you don't
know the encoding, keeping the bytes form is obviously recommended.

I don't know how often this happens.

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] Breaking undocumented API

[Eric Smith]

On 11/10/2010 11:58 AM, Tres Seaver wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/09/2010 11:12 PM, Stephen J. Turnbull wrote:

Nick Coghlan writes:

  >  >  Module writers who compound the error by expecting to be imported
  >  >  this way, thereby bogarting the global namespace for their own
  >  >  purposes, should be fish-slapped. ;)
  >
  >  Be prepared to fish-slap all of python-dev then - we use precisely
  >  this technique to support optional acceleration modules. The pure
  >  Python versions of pairs like profile/_profile and heapq/_heapq
  >  include a try/except block at the end that does the equivalent of:
  >
  >try:
  >  from _accelerated import * # Allow accelerated overrides
  >except ImportError:
  >  pass # Use pure Python versions

But these identifiers will appear at the module level, not global, no?
Otherwise this technique couldn't be used.  I don't really understand
what Tres is talking about when he writes "modules that expect to be
imported this way".  The *imported* module shouldn't care, no?  This
is an issue for the *importing* code to deal with.


Right -- "private" star imports aren't the issue for me, because the
same user who creates them is responsible for the other end fo the
stick.  I was ranting about library authors who document star imports as
the expected usage pattern for their external users.

Note that I still wouldn't use star imports in the "private
acceleration" case myself.  I would prefer a pattern like:

- --- $<  -
# spam.py

# Pure python API implementation
def foo(spat, blarg):
 ...

def bar(qux):
 ...

# Replace with accelearated C implemenataion
try:
 import _spam
except ImportError:
 pass # accelerated version not available
else:
 foo = _spam.foo
 bar = _spam.bar
- --- $<  -

This explicit name remapping catches unintentional erros (e.g., _spam
renames a method) better than the star import.


But then you're saying that all implementations of _spam have to support 
the same API. What if CPython's _spam has foo, bar, and baz, but 
Jython's only has foo and bar, and IronPython's only has baz? Without 
getting into special casing or lots of try/catch blocks on individual 
names, I think import * is the best way to go.


Eric.
___
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] Removal of Win32 ANSI API

[Nick Coghlan]

On Fri, Nov 12, 2010 at 5:26 AM, Victor Stinner
 wrote:
> On Thursday 11 November 2010 17:07:28 Hirokazu Yamamoto wrote:
>> Hello. Is it possible to remove Win32 ANSI API (ie: GetFileAttributesA)
>> and only use Win32 WIDE API (ie: GetFileAttributesW)?
>> Mainly in posixmodule.c.
>
> Even if I hate the MBCS encoding, because it replaces undecodable characters
> by similar glyphs by default, I'm not certain that it is a good idea to drop
> the bytes API. Can it be a problem to port programs from Python2 to Python3?
> Do major Python2 programs/libraries rely on the bytes API?
>
>> I think we can simplify the code hugely. (This means droping bytes
>> support for os.stat etc on windows)
>
> Sure, it will divide the number of lines, of the code specific to Windows, by
> two.

Can we get most of the code cleanup benefit without the backwards
compatibility risk by doing the decode from 'mbcs' on our side of the
fence?

That is, have code that was the C equivalent of:

arg_is_bytes = not isinstance(arg, str)
if arg_is_bytes:
  val = _decode_mbcs(arg)
  # Decoding error checking here
else:
  val = arg
# Common processing using WIDE API
if arg_is_bytes:
  result = _encode_mbcs(wide_result)
  # Encoding error checking here
else:
  result = wide_result

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] Breaking undocumented API

[Nick Coghlan]

On Fri, Nov 12, 2010 at 4:16 AM, Steven D'Aprano  wrote:
> Another couple of objections to getting rid of __all__:
>
> If you're proxying modules or built-ins, you may not be able to use a
> _private name, but you may not want import * to pick up your proxies.
>
> I find it annoying to see this:
>
> import module as _module
> _module.func()
>
> (instead of import module and merely leaving module out of __all__)

That gets us back to dir() and help() giving the wrong impression of
the module's public API though.

The issue I have is that the current policy (public APIs may or may
not be in all, private APIs may or may not be prefixed by a leading
underscore) makes it impossible to reliably extract a module's public
API programmatically.

If we instead adopt the explicit policy that private APIs are:
- imported modules (with the exception of os.path)
- any names starting with a leading underscore

Then we get the 3 API tiers you describe: core public API in __all__,
other public functions and globals without leading underscores,
private API with leading underscores (or imported modules).

We could even add two additional functions to the inspect module (e.g.
getpublicnames() and getimportstarnames()) which applied the relevant
filtering rules.

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] Breaking undocumented API

[Greg Ewing]

Nick Coghlan wrote:


My personal opinion is that we should be trying to get the standard
library to the point where __all__ definitions are unnecessary - if a
name isn't in __all__, it should start with an underscore (and if that
is true, then the __all__ definition becomes effectively redundant).


What about names imported from other modules that are used by
the module, but not intended for re-export? How would you
prevent them from turning up in help() etc. without using
__all__?

--
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] Removal of Win32 ANSI API

[André Malo]

On Thursday 11 November 2010 20:50:35 Martin v. Löwis wrote:
> > Even if I hate the MBCS encoding, because it replaces undecodable
> > characters by similar glyphs by default, I'm not certain that it is a
> > good idea to drop the bytes API. Can it be a problem to port programs
> > from Python2 to Python3? Do major Python2 programs/libraries rely on the
> > bytes API?
>
> I don't actually know for a fact, but I expect that the answer is "no".
>
> The questions is: where do file names typically come from? My guess
> is that they come from
> a) hard-coded strings in the source code
> b) command line arguments/environment variables

[...]

> In case b), they will be Unicode strings in Python 3.

But not neccessarily with unicode semantics if I get the discussions about the 
environment topic right.

Additionally:

d) Over a socket (like the HTTP protocol) -> Bytes.

nd
___
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