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
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)
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:
>
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
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 fo
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 wou
> 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
> 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-
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
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 stand
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 (whi
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)
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 e
> 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://
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 lik
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 appropr
>> 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
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 co
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
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 window
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
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 __al
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 mea
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 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__ definitio
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 moderni
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
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__
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 i
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 unde
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 co
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 docu
-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 remov
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 basicall
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.
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
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,
37 matches
Mail list logo
