[Python-Dev] Descriptions in unittest and avoiding confusion

For the edification of all involved, this post summarizes a somewhat surprising behavior in unittest around docstrings. In bpo-46126, I reported an issue where I’d observed that CPython developers were avoiding the use of docstrings in unittests due to what w

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

, and make us need to rethink our approach. So what Steve Downer described as "remain compatible within a single 3.x release", seems like exactly what we want. I support that level of compatibility guarantee. Could we keep that guarantee with this change? Tha

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

The PyTorch team plans to use PEP 523 as a part of PyTorch 2.0, so this proposal may break the next major release of PyTorch. The related project is TorchDynamo, which can be found here: https://github.com/facebookresearch/torchdynamo We will likely move this into the core of PyTorch closer to r

[Python-Dev] Re: Make __mro_entries__ mandatory for non-types

Steven D'Aprano wrote: > On Sat, Mar 05, 2022 at 04:42:55PM -0000, Jason Madden wrote: > > zope.interface relies on this behaviour. > > The example you give shows that Interface is a class. It merely has a > metaclass which is not `type`. (I presume that is what's g

[Python-Dev] Re: Make __mro_entries__ mandatory for non-types

Steven D'Aprano wrote: > On Sat, Mar 05, 2022 at 11:27:44AM +0200, Serhiy Storchaka wrote: > > Currently the class can inherit from arbitrary objects, not only types. > > Is that intentionally supported? > I know that metaclasses do not have to be actual classes, they can be > any callable with th

[Python-Dev] Re: Windows buildbots may be broken

umaran Sent: Tuesday, August 3, 2021 09:29 To: Jason R. Coombs Cc: python-dev@python.org Subject: Re: [Python-Dev] Windows buildbots may be broken On Fri, Jul 30, 2021 at 02:28:08PM +, Jason R. Coombs wrote: > If you run such a buildbot, please consider running this command on >

[Python-Dev] Windows buildbots may be broken

Jeremy informed me that due to a race condition on a test file and the CPython repo configuration for newline conversion, build bots on Windows may now be failing. If you run such a buildbot, please consider running this comma

[Python-Dev] Re: [python-committers] [RELEASE] Python 3.8.1rc1 is now available for testing

I think I missed the announcement of the cutoff date for 3.8.1; I was hoping to get some bug fixes in for importlib.metadata. These aren’t crucial bugfixes, but it would be nice not to have them linger for months. Would you consider including these,

[Python-Dev] Re: Restricted Entry Point from PEP-551/578

UMM6EML35MY76QPAP7PQVNEHBY/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Jason Killen jsnk...@gmail.com Pain is inevitable, misery is optional. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-de

[Python-Dev] Re: Restricted Entry Point from PEP-551/578

u, Nov 21, 2019 at 4:30 PM Christian Heimes wrote: > On 21/11/2019 21.19, Jason Killen wrote: > > I knew the audit hooks were new but didn't realize they were quite that > > new. I didn't mean to come across as pejorative asking if people cared > > about this. The fa

[Python-Dev] Re: Restricted Entry Point from PEP-551/578

m glad somebody is thinking about these types of things and I'd love to help if I can. On Thu, Nov 21, 2019 at 2:49 PM Christian Heimes wrote: > On 21/11/2019 18.27, Jason Killen wrote: > > I sent in a couple of PRs, accepted and merged (Thanks!), lately that > > switch to usi

[Python-Dev] Re: Restricted Entry Point from PEP-551/578

n doesn't even get you in the right neighborhood. Can we include a link in the PEP? On Thu, Nov 21, 2019 at 1:09 PM Steve Dower wrote: > On 21Nov2019 0927, Jason Killen wrote: > > I sent in a couple of PRs, accepted and merged (Thanks!), lately that > > switch to using io.open_cod

[Python-Dev] Restricted Entry Point from PEP-551/578

#x27;s the code: I'm very open to suggestions. I basically have no idea what I'm doing. I haven't touched C in about 7 years so don't expect the Mona Lisa. https://github.com/python/cpython/compare/master...jsnklln:PEP551_restricted_entry_point -- Jason

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

> On Feb 14, 2019, at 3:44 AM, Antoine Pitrou wrote: > > On Thu, 14 Feb 2019 00:57:36 -0500 > Jason Swails wrote: >> >> I literally just ran into this problem now. Part of a software suite I've >> written uses Python to fetch updates during the installa

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

nywhere. But they had python3. I suspect suddenly not having any "python" executable in a Linux system will screw up a lot more people than just me. The workaround was ugly. I'd like to see there always be a `python` executable available if any version of Python is installed. Than

[Python-Dev] __getattribute__'s error is not available in __getattr__

_getattr__ is called. Two more quick context comments: python is awesome, thank you all for your hard work; and I've been writing python almost every day for ~ 5 years now and I can do all the "black magic" jazz, so I'll be okay with an implementat

[Python-Dev] Another case for frozendict

I repeatedly run into situations where a frozendict would be useful, and every time I do, I go searching and find the (unfortunately rejected) PEP-416. I'd just like to share another case where having a frozendict in the stdlib would be useful to me. I was interacting with a database and had a

[Python-Dev] Python 3.3.4150

ot opening any window. I have tried with admin user and non-admin user. Is this expected behavior? Please advise and thanks for your help. Jason [http://intranet.ds.global/technology/employees/Documents/Communication%20Resource%20Center/Small%20logo%20for%20signature.png] Jason Burgoon A

Re: [Python-Dev] Virtualenv not portable from Python 2.7.2 to 2.7.3 (os.urandom missing)

Carl, I've drafted some notes: http://piratepad.net/PAZ3CEq9CZ Please feel free to edit them. If you want to chat, I can often be reached on freenode as 'jaraco' or XMPP at my e-mail address if you want to sprint on this in real-time. Does the issue only exist for Python 2.6 and 2.7? I'm not fa

Re: [Python-Dev] Virtualenv not portable from Python 2.7.2 to 2.7.3 (os.urandom missing)

ss of virtualenv. Nevertheless, virtualenv has become the defacto technique for Python environments. Putting my sysops cap on, I might perceive this change as being unannounced (w.r.t. Python) and having significant impact on operations. I would think this impact deserves at least a note in t

[Python-Dev] Virtualenv not portable from Python 2.7.2 to 2.7.3 (os.urandom missing)

missing (because the env includes the python 2.7.2 executable and stdlib). I suspect this change is going to cause some significant backward compatibility issues. Is there a recommended workaround? Should I file a bug? Regards, Jason smime.p7

Re: [Python-Dev] Script(s) for building Python on Windows

> From: python-dev-bounces+jaraco=jaraco@python.org [mailto:python- > dev-bounces+jaraco=jaraco@python.org] On Behalf Of Jason R. Coombs > Sent: Monday, 16 January, 2012 19:01 > > I'm unsure if the conversion from 9 to 10 or 10 to 9 can be as simple as the > vs9to8 s

Re: [Python-Dev] Script(s) for building Python on Windows

> From: "Martin v. Löwis" [mailto:mar...@v.loewis.de] > Sent: Monday, 16 January, 2012 16:25 > > I'd be hesitant to put too many specialized tools into the tree that will > become unmaintained. Please take a look at the vs9to8 tool in PCbuild; if you > could adjust that to support VS 10, it would b

Re: [Python-Dev] Script(s) for building Python on Windows

> From: Brian Curtin [mailto:br...@python.org] > Sent: Monday, 16 January, 2012 15:20 > > 2010 is adequate for limited use but the test suite doesn't pass, so I would be > hesitant to add support and/or documentation for building with it until we > actually support it the same as or in place of 200

[Python-Dev] Script(s) for building Python on Windows

co.develop modules and into a portable script and put together a proof-of-concept in the default branch. The build script should not interfere with any build bots or other existing build processes, but should enable another more powerful technique for producing builds. I look forward to your co

Re: [Python-Dev] [Python-checkins] cpython (2.7): PDB now will properly escape backslashes in the names of modules it executes.

, 2011 10:10 > To: python-dev@python.org > Subject: Re: [Python-Dev] [Python-checkins] cpython (2.7): PDB now will > properly escape backslashes in the names of modules it executes. > > Hi Jason, > > > http://hg.python.org/cpython/rev/f7dd5178f36a > > branch:

Re: [Python-Dev] new LRU cache API in Py3.2

d the ActiveState recipes for simple caches, but in almost every case, I've had to adapt the implementation to provide more transparency. I'd prefer to not have to do the same with the stdlib. Regards, Jason R. Coombs # modified from http://code.activestate.com/recipes/498245-lru-and-l

Re: [Python-Dev] [Distutils] At least one package management tool for 2.7

On Wed, Mar 24, 2010 at 12:53 PM, Darren Dale wrote: > On Wed, Mar 24, 2010 at 1:19 PM, Ian Bicking wrote: > > On Wed, Mar 24, 2010 at 7:27 AM, Olemis Lang wrote: > >> My experience is that only `install_requires` is needed (unless you > >> want to create app bundles AFAICR) , but in practice I

Re: [Python-Dev] PyPI governance

On Fri, Nov 13, 2009 at 6:44 PM, Chris Withers wrote: > PS: While I'm sure a lot of python-dev people are interested in this topic, > I'm pretty sure this whole huge sprawling thread belongs on catalog-sig... +100 ___ Python-Dev mailing list Python-Dev@

Re: [Python-Dev] PyPI comments and ratings, *really*?

On Thu, Nov 12, 2009 at 10:19 AM, Antoine Pitrou wrote: > (more seriously, the problem with a comment system is that once it takes off, > you need a whole array of functionalities to maintain a good S/N ratio. Just > allowing people to "comment" without any sort of moderation, filtering or > commu

Re: [Python-Dev] PyPI comments and ratings, *really*?

On Thu, Nov 12, 2009 at 8:06 AM, Jesse Noller wrote: > On Thu, Nov 12, 2009 at 8:38 AM, Steven D'Aprano wrote: >> On Thu, 12 Nov 2009 08:44:32 pm Ludvig Ericson wrote: >>> Why are there comments on PyPI? Moreso, why are there comments which >>> I cannot control as a package author on my very own

Re: [Python-Dev] functools.compose to chain functions together

, fundamental application, especially with respect to functional programming. I'm not arguing that just because Jason needs it, it should be in the standard library. Rather, I just wanted to express that, like Chris AtLee, I would find this function quite useful. As Steven pointed out, th

Re: [Python-Dev] functools.compose to chain functions together

Steven D'Aprano wrote: > Sent: Sunday, 16 August, 2009 08:15 > > On Sat, 15 Aug 2009 04:39:03 am Jason R. Coombs wrote: > > > > > def meta_decorator(data): > > return compose(dec_register_function_for_x, dec_alter_docstring, > > dec_inject_some_dat

[Python-Dev] functools.compose to chain functions together

ieve functools is the ideal location for a very basic and general capability such as composition. I realize this patch was rejected, but I'd like to propose reviving the patch and incorporating it into functools. Regards, Jason smime.p7s Description: S/MIME cryptographic signature

[Python-Dev] 2.6.3 unittest change breaks nose (issue 6418)

Bringing python-dev into the discussion at Barry's request. The summary is that a recent change to unittest.TestProgram breaks nose by moving self.testRunner initialization from it's old home in TestProgram.runTests to TestProgram.__init__. The very small patch attached to the ticket moves it back

[Python-Dev] Mercurial, linefeeds, and Visual Studio

unity in case anyone else runs into this issue. Also, if there's a recommended procedure for addressing this issue (and others that might arise due to non-native line endings), I'd be interested to hear it. Regards, Jason ___ Python-Dev mail

Re: [Python-Dev] Python 2.6.2 and 3.0.2

I'm still holding my breath for Python 2.6.2, which fixes a Windows DLL linking issue that was already fixed in 3.0.1. Obviously, the proposed schedule has passed, but I would prefer a release sooner than later. Of course, that's just my preference. Regards, Jason > -BEG

Re: [Python-Dev] opcode dispatch optimization

On Wed, Dec 31, 2008 at 11:44 AM, Christian Heimes wrote: > The patch makes use of a GCC feature where labels can be used as values: > http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html . I didn't know > about the feature and got confused by the unary && operator. Right. SpiderMonkey (Mozil

Re: [Python-Dev] ',' precedence in documentation

What I really want is for the need to be less common. What if assert recognized certain commonly used expression types and actually generated appropriate error messages? >>> assert foo.answer == 42 AssertionError: expected foo.answer == 42; actual: 'a suffusion of yellow' Maybe that's too ma

Re: [Python-Dev] __eq__ vs hash

On Fri, Apr 4, 2008 at 9:38 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > What specific code breaks? Maybe we need to turn this into a warning > in order to be more backwards compatible? I looked at Mercurial. It doesn't use __hash__ at all. It uses __eq__ in two files, three total uses: h

[Python-Dev] How to change path at compile time?

Hello, Is there any reasonable way to change the default sys.path at compile time? (ie. add a directory). (I am aware of $PYTHONPATH for runtime) -- Best Regards, Jason Garber Senior Systems Engineer IonZoft, Inc. (814) 941-2390 [EMAIL PROTECTED] <mailto:[EMAIL PROTEC

Re: [Python-Dev] [poll] New name for __builtins__

On Nov 29, 2007 11:54 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > But then I thought, what if we renamed the __builtin__ module instead > to builtins, and left __builtins__ alone? Hmm. __builtins__ is a magic hook, but __builtin__-the-module isn't the thing it hooks, exactly, not the way __

Re: [Python-Dev] Removing the GIL (Me, not you!)

On 9/13/07, Justin Tulloss <[EMAIL PROTECTED]> wrote: > 1. Use message passing and transactions. [...] > 2. Do it perl style. [...] > 3. Come up with an elegant way of handling multiple python processes. [...] > 4. Remove the GIL, use transactions for python objects, [...] The SpiderMonkey JavaSc

Re: [Python-Dev] Removing the GIL (Me, not you!)

On 9/12/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Now we are getting into details: you do NOT have to lock > an object to modify its reference count. An atomic > increment/decrement operation is enough. One could measure the performance hit incurred by using atomic operations for refcount

Re: [Python-Dev] Order of operations

On 8/29/07, Dirkjan Ochtman <[EMAIL PROTECTED]> wrote: > Alexandre Vassalotti wrote: > > C doesn't have an exponentiation operator. You use the pow() function, > > instead: > > Wouldn't it make more sense, then, to have unary +/- have higher > precedence than the ** operator, so that -3**2 == 9?

Re: [Python-Dev] Wither PEP 335 (Overloadable Boolean Operators)?

On 5/18/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > While reviewing PEPs, I stumbled over PEP 335 ( Overloadable Boolean > Operators) by Greg Ewing. -1. "and" and "or" affect the flow of control. It's a matter of taste, but I feel the benefit is too small here to add another flow-control q

[Python-Dev] Patch reviews and request

OK, here's the patch I'd like to direct attention to: http://python.org/sf/1704134 [ 1704134 ] minidom Level 1 DOM compliance This is only the first step toward DOM Level 1 compliance. It fixes the stuff that's easy to fix. Here are the patch reviews. I put more detailed comments in the SF

Re: [Python-Dev] minidom -> new-style classes?

On 4/17/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Perhaps a rewrite could target 3.0 and 2.6 could use a backported > version of this *if* py3k compatibility mode is enabled? I'd love to > see at least the 3.0 version cleaned up. A lot of these bugs can be fixed without forking. I've been

[Python-Dev] minidom -> new-style classes?

I'm working on minidom's DOM Level 1 compliance, targeting Python 2.6. We have some bugs involving DOM property behavior. For example, setting the nodeValue attribute of an Element is supposed to have no effect. We don't implement this. The right way to implement these quirks is using new-style

Re: [Python-Dev] minidom and DOM level 2

On 4/13/07, Andrew Clover <[EMAIL PROTECTED]> wrote: > Jason Orendorff wrote: > > I don't suppose you'd be willing to update it for Python 2.5, would you? > > Can do, but at this point I'm not aware of any work having been done on > the issues listed there

Re: [Python-Dev] minidom and DOM level 2

On 4/7/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > In any case, the *claim* certainly is that minidom supports > level 2 core. Any proof to the contrary indicates a bug; > patches are welcome. OK-- I'll work on this. I can fix the easy ones, anyway. -j

Re: [Python-Dev] minidom and DOM level 2

On 4/7/07, Andrew Clover <[EMAIL PROTECTED]> wrote: > Jason Orendorff wrote: > > OK, I think this is worthwhile then. :) I'll read the spec and submit > > a patch. > > You're planning to implement EntityReference in minidom? That'll be fun! > :-)

[Python-Dev] Hindsight on Py_UNICODE_WIDE?

6-bit, and some 32-bit--each string uses the narrowest possible representation). This has been discussed here for Python 3000. My question is: Is this for real? How far along is it? How likely is it? Thanks, Jason ___ Python-Dev mailing list Python

Re: [Python-Dev] minidom and DOM level 2

On 3/23/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Jason Orendorff schrieb: > > The lib ref claims that minidom supports DOM Level 1. Does anyone > > know what parts of Level 2 are not implemented? I wasn't able to find > > anything offhand. &g

[Python-Dev] minidom and DOM level 2

The lib ref claims that minidom supports DOM Level 1. Does anyone know what parts of Level 2 are not implemented? I wasn't able to find anything offhand. It seems to be more a matter of what's not documented, or what's not covered by the regression tests. So. I'd be happy to do some diffing be

Re: [Python-Dev] Patch 1644818: Allow importing built-in submodules

On 3/12/07, Miguel Lobo <[EMAIL PROTECTED]> wrote: > Anyway, I'm intrigued about this "review 5 other patches" procedure you > suggest. What exactly would be involved in such a review? Please note that > I hadn't touched CPython code before I wrote my patch and I haven't been > following CPython

[Python-Dev] [ 1669539 ] Change (fix!) os.path.isabs() semantics on Win32

On 3/7/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Terry Jones schrieb: > > I do think the behavior can be improved, and that it should be fixed, but > > at a place where other incompatible changes will also be being made, > > Indeed, 2.6 is such a place. Any feature release can contain > in

Re: [Python-Dev] Encouraging developers

On 3/5/07, A.M. Kuchling <[EMAIL PROTECTED]> wrote: > Any ideas for fixing this problem? The current developer FAQ says: 2.4 How can I become a developer? There's only one way to become a developer, and that's through the School of Hard Knocks. http://mail.python.org/pipermail/python-de

Re: [Python-Dev] PyFAQ: thread-safe interpreter operations

On 11/27/06, Aahz <[EMAIL PROTECTED]> wrote: > On Mon, Nov 27, 2006, Jason Orendorff wrote: > > Way back on 11/22/06, "Martin v. L?wis" <[EMAIL PROTECTED]> wrote: > >> [...] I can find nothing wrong with people relying on > >> reference countin

Re: [Python-Dev] PyFAQ: thread-safe interpreter operations

Way back on 11/22/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Nick Coghlan schrieb: > > Martin v. Löwis wrote: > >> I personally consider it "good style" to rely on implementation details > >> of CPython; > > > > Is there a 'do not' missing somewhere in there? > > No - I really mean it. I ca

Re: [Python-Dev] PEP 355 status

On 9/30/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > OK. Pronouncement: PEP 355 is dead. [...] > > It would be terrific if you gave us some clue about what is > wrong in PEP355, [...] Here are my guesses. I believe Guido rejected this PEP for a lot of reasons. By th

Re: [Python-Dev] Caching float(0.0)

On 9/29/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > (I just checked the program I'm working on, and my analysis tells me > that the most common floating point value in that program is 121.216, > which occurs 32 times. from what I can tell, 0.0 isn't used at all.) *bemused look* Fredrik, can y

[Python-Dev] Document performance requirements?

On 7/21/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > However, I'm also struggling to think of a case other than list vs deque where > the choice of a builtin or standard library data structure would be dictated > by big-O() concerns. OK, but that doesn't mean the information is unimportant. +1 o

Re: [Python-Dev] A Horrible Inconsistency

On 5/26/06, Facundo Batista <[EMAIL PROTECTED]> wrote: > I think that we can do one of the following, when we found "-1 * (1, 2, 3)": > > - Treat -1 as 0 and return an empty tuple (actual behavior). > - Treat the negative as a reverser, so we get back (3, 2, 1). > - Raise an error. No, no, no. Th

Re: [Python-Dev] total ordering.

Vladimir, Your examples seem to indicate that you've misunderstood the change that's proposed for Python 3000. Especially this: On 5/17/06, Vladimir 'Yu' Stepanov <[EMAIL PROTECTED]> wrote: > # BEGIN: Emulation python3000 > if type(a) is not type(b) and ( >

Re: [Python-Dev] total ordering.

On 5/11/06, Vladimir 'Yu' Stepanov <[EMAIL PROTECTED]> wrote: > If for Python-3000 similar it will be shown concerning types > str(), int(), complex() and so on, and the type of exceptions > will strongly vary, it will make problematic redefinition of > behavior of function of sorting. I don't see

Re: [Python-Dev] PEP 3102: Keyword-only arguments

On 4/30/06, Edward Loper <[EMAIL PROTECTED]> wrote (referring to keyword-only arguments): > I see two possible reasons: > >- A function's author believes that calls to the function will be > easier to read if certain parameters are passed by name, rather > than positionally; and they

Re: [Python-Dev] PEP 355 (object-oriented paths)

Talin, everything you wrote is really compelling. If path.py weren't so ridiculously useful to me, I would be completely convinced. :) For example, I agree 100% with this: > Another reason why I am a bit dubious about a class-based approach > is that it tends to take anything that is related to

Re: [Python-Dev] String initialization (was: The "i" string-prefix: I18n'ed strings)

A compiler hook on string initialization, eh? I have a distantly related story--this isn't important, just another random Python use case for the file. (The i"xyzzy" proposal wouldn't help this case.) In scons, your SConscripts (makefiles, essentially) are Python source code. You typically have

[Python-Dev] bytes thoughts

1. Maybe there should be a more obvious way to spell "bytes([0])*N". I went through "bytes([0]*N)" and "bytes('\0'*N)" before I realized there was a memory-efficient way to do it. 1a. Likewise, slice-assignment nicely handles memmove(), but there's no memset(). 2. Having a plural noun as a typ

Re: [Python-Dev] Pre-PEP: The "bytes" object

Neil Schemenauer wrote: > Ron Adam <[EMAIL PROTECTED]> wrote: >> Why was it decided that the unicode encoding argument should be ignored >> if the first argument is a string? Wouldn't an exception be better >> rather than give the impression it does something when it doesn't? > >From the PEP: > >

Re: [Python-Dev] Pre-PEP: The "bytes" object

On 2/22/06, Neil Schemenauer <[EMAIL PROTECTED]> wrote:     @classmethoddef fromhex(self, data):data = "" '', data)return bytes(binascii.unhexlify(data))If it's to be a classmethod, I guess that should be "return self( binascii.unhexlify(data))".-j __

Re: [Python-Dev] Path PEP: some comments (equality)

On 2/20/06, Mark Mc Mahon <[EMAIL PROTECTED]> wrote: It seems that the Path module as currently defined leaves equalitytesting up to the underlying string comparison. My guess is that thisis fine for Unix (maybe not even) but it is a bit lacking for Windows. Should the path class implement an __eq_

Re: [Python-Dev] bytes.from_hex() [Was: PEP 332 revival in coordination with pep 349?]

On 2/15/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: >  Actually users trying to figure out Unicode would probably be better served> if bytes.encode() and text.decode() did not exist.[...]It would be better if the signature of text.encode() always returned a bytes object. But why deny the bytes

[Python-Dev] bytes.from_hex() [Was: PEP 332 revival in coordination with pep 349?]

Instead of byte literals, how about a classmethod bytes.from_hex(), which works like this:   # two equivalent things   expected_md5_hash = bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')   expected_md5_hash = bytes([92, 83, 80, 36, 202, 197, 25, 145, 83, 227, 131, 79, 229, 201, 46, 106]) It's

Re: [Python-Dev] / as path join operator

On 1/28/06, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote: > Please note that my point was entirely different from trying to decide > whether to subclass strings. Noted -- sorry I took you out of context there; that was careless. > Jason> Filesystem paths are in fact string

Re: [Python-Dev] / as path join operator

It's controversial that Path subclasses str. Some people think it's flat-out wrong. Even Bjorn argues that it's a practicality-vs-purity tradeoff. But a strong argument can be made that Path *should* be a string subclass, practicality be damned. Proof follows. I. Here's an example of the sort

Re: [Python-Dev] The path module PEP

On 1/24/06, Ian Bicking <[EMAIL PROTECTED]> wrote: > There's kind of a lot of methods in here, which is a little bothersome. > It also points towards the motivation for the class -- too many > options in too many places in the stdlib. But throwing them *all* in > one class consolidates but doesn't

Re: [Python-Dev] The path module PEP

On 1/25/06, Toby Dickenson <[EMAIL PROTECTED]> wrote: > On Tuesday 24 January 2006 20:22, BJörn Lindqvist wrote: > > #Replacing glob.glob > > glob.glob("/lib/*.so") > > ==> > > Path("/lib").glob("*.so") > > This definition seems confusing because it splits the glob pattern string in

Re: [Python-Dev] The path module PEP

Thanks for doing this. I'm not sure anyone that matters here is actually keen on path, but I guess we'll see. A few comments: On 1/24/06, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > The following points summarizes the design: > > - Path extends from string, therefore all code which expe

Re: [Python-Dev] PEP 343 and __context__()

On 1/20/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Jason Orendorff wrote: > > DecimalContext has a few problems. In code where it matters, every > > function you write has to worry about it. (That is, you can't just > > write __decimal_context__ = ... at

[Python-Dev] PEP 343 and __context__()

I just noticed that my name is in PEP 343 attached to the idea of the __context__() method, and I'm slightly queasy over it. The rationale was to help e.g. decimal.DecimalContext support 'with'. Maybe that's a bad idea. DecimalContext has a few problems. In code where it matters, every function

Re: [Python-Dev] basenumber redux

On 1/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Alex Martelli wrote: > > But this doesn't apply to the Python Standard Library, for example see > > line 1348 of imaplib.py: "if isinstance(date_time, (int, float)):". > [...] > > Being able to change imaplib to use basenumber instead of (i

Re: [Python-Dev] str with base

On 1/18/06, Donovan Baarda <[EMAIL PROTECTED]> wrote: > I think supporting arbitrary bases for floats is way overkill and not > worth considering. If you mean actual base-3 floating-point arithmetic, I agree. That's outlandish. But if there were a stdlib function to format floats losslessly in h

Re: [Python-Dev] str with base

It seems dumb to support *parsing* integers in weird bases, but not *formatting* them in weird bases. Not a big deal, but if you're going to give me a toy, at least give me the whole toy! The %b idea is a little disappointing in two ways. Even with %b, Python is still dumb by the above criterion

Re: [Python-Dev] Ph.D. dissertation ideas?

Brett, You could create a downloadable corpus of Python source code, and maybe a web site through which people can easily browse/search it, contribute to it, and maintain it. The point would be to support language designers, tool developers, and researchers. Several python-dev folks have their o

Re: [Python-Dev] ElementTree in stdlib

Guido van Rossum wrote: > On 12/13/05, Walter Dörwald <[EMAIL PROTECTED]> wrote: > > Having to define classes that conform to a certain API and registering > > instances of those classes as callbacks with the parser doesn't look > > that pythonic to me. An iterator API seems much more pythonic. > >

Re: [Python-Dev] ElementTree in stdlib

On 12/13/05, Walter Dörwald <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > I don't think that SAX is unpythonic, but it's pretty low-level and > > mostly of use to people writing higher-level XML parsers (my parsexml > > module uses it). > > Having to define classes that conform to a cert

Re: [Python-Dev] PEP 8 updates/clarifications

Barry Warsaw wrote: > - If your class is intended to be subclassed, and you have attributes > that you do not want subclasses to use, consider naming them with > double leading underscores and no trailing underscores. This invokes > Python's name mangling algorithm, w

Re: [Python-Dev] Jython and CPython

On 12/13/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: Fredrik Lundh wrote:> BTW, what's the policy wrt. Jython-specific modules in the standard library?I don't think there is enough precedence to have a policy. So far, theonly places that explicitly support Jython is the test suite, pickle, and

Re: [Python-Dev] Divorcing str and unicode (no more implicit conversions).

-1 on keeping the source encoding of string literals. Python should definitely decode them at compile time. -1 on decoding implicitly "as needed". This causes decoding to happen late, in unpredictable places. Decodes can fail; they should happen as early and as close to the data source as possi

Re: [Python-Dev] Proposed changes to PEP 343

On 10/7/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > the whole concept might be perfectly fine on the "this construct corre- > sponds to this code" level, but if you immediately end up with things that > are not what they seem, and names that don't mean what the say, either > the design or the de

Re: [Python-Dev] __doc__ behavior in class definitions

Martin, These two cases generate different bytecode. def foo(): # foo.func_code.co_flags == 0x43 print x# LOAD_FAST 0 x = 3 class Foo: # .co_flags == 0x40 print x# LOAD_NAME 'x' x = 3 In functions, local variables are just numbered slots.

Re: [Python-Dev] PEP 343 and __with__

Right after I sent the preceding message I got a funny feeling I'm wasting everybody's time here. I apologize. Guido's original concern about speedy C implementation for locks stands. I don't see a good way around it. By the way, my expansion of 'with' using coroutines (in previous message) was

Re: [Python-Dev] PEP 343 and __with__

The argument I am going to try to make is that Python coroutines need a more usable API. > Try to explain the semantics of the with statement without referring to the > __enter__ and __exit__ methods, and then see if you still think they're > superfluous ;) > > The @contextmanager generator decora

Re: [Python-Dev] PEP 343 and __with__

Phillip J. Eby writes: > You didn't offer any reasons why this would be useful and/or good. It makes it dramatically easier to write Python classes that correctly support 'with'. I don't see any simple way to do this under PEP 343; the only sane thing to do is write a separate @contextmanager gen

[Python-Dev] PEP 343 and __with__

I'm -1 on PEP 343. It seems ...complex. And even with all the complexity, I *still* won't be able to type with self.lock: ... which I submit is perfectly reasonable, clean, and clear. Instead I have to type with locking(self.lock): ... where locking() is apparently either a new built

Re: [Python-Dev] Adding a conditional expression in Py3.0

On 9/20/05, Guido wrote: > On 9/20/05, Jason Orendorff <[EMAIL PROTECTED]> wrote: > > return (if q: q.popleft() else: None) > > return (if q then q.popleft() else None) > > return q ? q.popleft() : None > > > > Hmmm. Score one for ?:. > >

[Python-Dev] Wanting to learn

Hi My name is Jason & i have a great interest in progamming whether it be python or what have you. From my understanding Python is written in C right ? I am willing to do grunt work just to learn .I a quick to catch on given the right path to follow.Please let me know if you will let me l

Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)

Concerning names for partition(), I immediately thought of break(). Unfortunately it's taken. So, how about snap()? head, sep, tail = line.snap(':') -j ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-de

  1   2   >