Re: [Python-Dev] Aaron Hall, Introduction and pull-request bump
Hello! And welcome aboard this mailing list ship. :) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default
I'm -1 on turning this on by default. As a Python developer, I want to be aware of when deprecations are introduced, but I don't want the users of my library or application to care or know if I don't address those deprecation warnings for a few months or a year. The right solution for me here seems to enable the warnings in CI pipelines / tests. As an end user, if I see deprecation warnings there's nothing I can really do to make them go away straight away except run Python with warnings turned off which seems to defeat the point of turning them on by default. The right solution here seems to be for authors to test their software before releasing. I'm -2 on a complicated rule for when warnings are on because I'm going to forget the rule a week from now and probably no one I work with on a day to day basis will even know what the rule was to start with. Maybe there are ways around these things, but I'm not really seeing what's wrong with the current situation that can't be fixed with slightly better CI setups (which are good for other reasons too). Schiavo Simon ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff
On Wed, Nov 8, 2017 at 10:33 PM, Nick Coghlan wrote: > For interactive use, the principle ends up being "Code you write gives > deprecation warnings, code you import doesn't" (which is the main > aspect I care about, since it's the one that semi-regularly trips me > up when I forget that DeprecationWarning is off by default). I with Antoine here. The idea that "code in __main__" is the set of code someone wrote really seems a lot like guessing (and not even very good guessing). If everyone follows the "keep __main__ small" then scripts won't automatically display deprecation warnings by default and so the original problem of "warnings are easy to miss" remains. Counter proposal -- why don't testing frameworks turn on warnings by default? E.g. like pytest-warnings? That way people running tests will see warnings and others won't unless they ask to see them. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Guido's Python 1.0.0 Announcement from 27 Jan 1994
We need a PPP! ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Guido's Python 1.0.0 Announcement from 27 Jan 1994
Python Party Proposal! ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Regular expression bytecode
This might be tricky for alternative Python implementations which might compile regular expressions into something rather different. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The pysandbox project is broken
Thanks for writing this email. It's well written and it takes a lot of character to stand up and say you went down the wrong road. While I'm here - thanks also for all your work on core Python. As a Python user I really appreciate it. Schiavo Simon ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] We cannot fix all issues: let's close XML security issues (not fix them)
On Thu, Sep 6, 2018 at 5:06 PM Ryan Gonzalez wrote: > Thought: what if there's a label on the bug tracker meaning roughly "we're > probably not going to fix this anytime soon, but we won't mind someone > stepping up"? Maybe "wouldlikehelpfixing"? :D ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] dear core-devs
Are there any core devs that Michael or Erik could collaborate with? Rather than rely on adhoc patch review from random core developers. Michael and Eric: Question -- are you interested in becoming core developers at least for the purposes of maintaining these platforms in future? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Arbitrary non-identifier string keys when using **kwargs
I would consider it a feature. My reasoning is that the restriction on what can be used as an identifier is a syntax restriction, not a general restriction on what attributes or names can be. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VxWorks and cpython?
It feels like it would be a good idea for Brian or someone else from Wind River to work towards becoming a core developer? If Brian, et al are interested, is there a core developer who would be willing to mentor them? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding shlex.join?
Software that "Just Works" and hasn't needed maintenance in years is the best software. :D ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library
Woot. +100 on this PEP. > If the stdlib didn't have NNTP support, obviously nobody would suggest > adding it nowadays. Perhaps this is a good reason to keep nntplib in the deprecation list? Another question is "are there any places using nntplib where `pip install nntplib`" is not an reasonable option? There's quite a lot of time before 3.10 to move nntplib into an outside package. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Expected stability of PyCode_New() and types.CodeType() signatures
As the maintainer of Genshi, one the libraries affected by the CodeType and similar changes, I thought I could add a users perspective to the discussion: Genshi is a templating engine that parses Python code from inside its templates. It supports Python 2.6+, 3.2+, pypy2 and pypy3. It parses Python using compile(...) and then walks the AST to, for example, translate variable lookups into template context lookups. Pretty much every major release of Python has broken Genshi's Python parsing in some way. While on the one hand this is a bit annoying, I also don't want Python to stop evolving where it makes sense. My requests to core developers are largely pragmatic: * Try not to change things unless there's a good reason to (i.e. it makes Python better). * Don't try declare that these things shouldn't be used (there is not much I can do about that now). * Do warn people that these things evolve with the language. * If changes do happen, try make them visible and give a clear description of what has changed. Also many thanks to the core developers who've submitted patches to update Genshi in the past -- that was awesome of you. The new CodeType.replace will remove some potential sources of breakages in the future, so thank you very much for adding that. Schiavo Simon ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Expected stability of PyCode_New() and types.CodeType() signatures
On Sat, Jun 1, 2019 at 12:29 AM Terry Reedy wrote: > We try not to. There is already too much work. > ... > That was removed from the PR before it was merged. > ... > That was merged. > ... > Another chunk was added to What's New. > Woot to all of these! :) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Steering Council Update for July 2019
Is there a way for people to give input to the challenges facing Python discussion? I'm picturing something like people writing short statements of perceived challenges and submitting them so that the SC has more ideas on its radar. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/SJJ5JY5LPL3OQF2GSZVUJ5PZSVW5USO3/
[Python-Dev] Re: Speeding up CPython
Since HPy was mentioned, hello from the HPy team! If anyone is thinking about Python performance or new Python VMs, we'd love them to take a look at HPy and come and talk to us. HPy is meant to provide a new C API layer that any Python VM could implement in order to efficiently support Python extensions written on top of HPy. Amazingly, such extensions would also be backwards compatible (i.e. they would also run on CPython as it exists today). If you'd like to talk to us (and we would like to talk to you) you can find us at: * Mailing list: hpy-...@python.org * IRC: hpy-...@python.org If you would like to contribute as a developer (or any other way), we're here to help (and at the moment I am prioritising landing other people's contributions pretty much full-time). If someone has money to donate, they can donate to the project at https://opencollective.com/hpy/contribute. We have quite a few contributors who could contribute more time than they do in exchange for money. HPy is currently in quite an early stage of development (we can already run some simple Python C extensions without any performance penalties on CPython). The upside is that right now we can consider almost any suggestion for improving HPy because none of the design is set in stone. In a few months it might be helpful to have people try porting some (many) C extensions to HPy to see how that goes. Yours happily, Simon Cross (random person working on HPy) ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ARSII7KMZZ5W6UMKR7LIQDIWFSWWYQLZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Speeding up CPython
On Wed, Oct 21, 2020 at 4:28 AM Terry Reedy wrote: > I don't think the two projects are mutually exclusive. 100% agreed. I would even go as far as to say that HPy and other proposals to improve Python are mutually beneficial. HPy aims to remove dependencies between C extensions and Python internals, so that Python internals can evolve more easily. Someone else still needs to do the evolving. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LRNDTBSPIM26ITQPQJER3UPQPLKSO5SS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Please do not remove random bits of information from the tutorial
I really enjoyed learning from this "user manual with a strong narrative component" so I would personally like to see it stay even if a new tutorial is created for a different kind of audience. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GENCYD7WLJTF34LGDC4TN4RXDPN7O2M3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Please do not remove random bits of information from the tutorial
On Mon, Nov 9, 2020 at 6:38 PM Chris Angelico wrote: > The name "tutorial" definitely screams "thing you should go through > first". It shouldn't have to teach you everything. Keep the tutorial > simple. That's quite subjective. Personally I prefer a more complete tutorial which explains many details so that I don't immediately run into fundamentals I don't understand when I start using what I've learned. K&R was very popular, so I don't think I'm alone in this. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4LWCOZ7IGFRO67BDUOG2G4FAJW6NTEWH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Please do not remove random bits of information from the tutorial
+1e6 + 5j # :) ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YRUHXXBY2AWT7QSXJ5373FYLQPASQVVH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Review patch fixing packed bitfields in ctypes struct/union
Hello! Thank you for this patch! I can't help land it, but it looks sane to me. I fear you have discovered a fundamental truth about ctypes though -- it tries to mimic what C compilers do and this inevitably leads to many discrepancies. E.g. if a C structure you're trying to use is wrapped in an #ifdef, one has to then try to mimic that ifdef in Python, which may be impossible or very fragile. If you're encountering such issues, you might save yourself future pain and bugs by switching to an alternative approach (cython, CFFI, struct module -- it depends on what problem you're trying to solve). Will hold thumbs that you find someone to review and merge the patch! Yours sincerely, Simon Cross ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HGU2WTLRHTCIR6D5VLSV7A5I3MW3PI5L/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Review patch fixing packed bitfields in ctypes struct/union
The PR already has a fair amount of good review and discussion. Me doing a superficial review is not going to help get it merged. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/B72DDTOXEZQ57GC2C2PWDOJ436IOLWR3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [RELEASE] Python 3.9.1rc1 is now ready for testing
Thank you release team and all the bug fix contributors! ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/QSNRO6R2OOJC6EMIFPT6MZ5HTMCSTKCM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: macOS issues with 3.8.7rc1
On Wed, Dec 9, 2020 at 2:17 PM Ronald Oussoren via Python-Dev wrote: > We know. Backporting the relevant changes to 3.8 is taking more time than I > had hoped. It doesn’t help that I’ve > been busy at work and don’t have as much energy during the weekend as I’d > like. Thank you for all your hard work on this! I've been in similar positions as a maintainer in the past (long work days and too tired to get to open source fixes in the evenings or on weekends). Please look after yourself -- it's better for everyone if the patch is delayed some months than to have you get burned out (or even just not enjoy contributing). Many open source contribution journeys begin with someone scratching an itch, so it's okay if there are itches for people to scratch. :D ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/27MUX65R52HZNGSIPNBRCC2ITFJUFMKM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Heap types (PyType_FromSpec) must fully implement the GC protocol
Hi Victor, Thank you for looking into these issues. They are very important to HPy too! HPy currently only supports head types for similar reasons to why they are important to sub-interpreters -- their lifecycle can be managed by the Python interpreter and they are not tied to the memory and life cycle of the dynamic library containing the C extension. E.g. with heap types the interpreter can control when a type is created and destroyed and when it can be accessed. We've run into some minor issues with the limitations in PyType_Slot (https://docs.python.org/3/c-api/type.html#c.PyType_Slot.PyType_Slot.slot) but we are working around them for the moment. It would be useful to have some sense of where PyType_FromSpec is headed -- e.g. is it a goal to have it support all of the features of static types in the future -- so that we can perhaps help suggest / implement small changes that head in the right direction and also ensure that HPy is aligned with the immediate future of the C API. Yours sincerely, Simon Cross ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GXZI7T2KGAU3BNKNW6E4CKDTECLZAUGX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Speeding up CPython
On Mon, Jan 25, 2021 at 1:30 AM Terry Reedy wrote: > The Python Software Foundation currently has a shortfall of funds rather > than a surplus. I believe Mark's proposal suggested raising money specifically for the project, not spending general PSF funds. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/CULJ7Z5M5CDO5DODF3D4EVKETT3VQXK7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: New public C API functions must not steal references or return borrowed references
On Thu, Mar 25, 2021 at 9:01 PM Mark Shannon wrote: > Maybe the problem is the term "stealing". > The caller is transferring the reference to the callee. > In some circumstances it can make a lot of sense to do so, since the > caller has probably finished with the reference and the callee needs a > new one. The problem with both borrowed and stolen references is that they implicitly expose the lifetime of the reference as part of the API. I agree that borrowed references are worse in some sense (there is no way to indicate that one is done with a borrowed reference at all). Stolen references are not great though. As you mention, in theory one can treat the stolen reference as having been DECREF'ed and never use it again, but in practice that's hard to do. When reviewing or writing code, one has to remember precisely which API functions steal a reference. One can no longer reason about whether the reference counting is correct by looking for appropriate DECREF's. It's very hard for tools to help pick up mistakes because the reference was freed -- just not necessarily at the right time. Of course it is hard to avoid these kinds of problems as long as pointers to PyObjects and reference counting are part of the API, but let's not make it more difficult to write correct code unless there is a really big advantage to be had by doing so. I also don't see the rules that Victor is proposing as absolutes. More of a "let's have a big conversation before doing this" kind of rule. - Simon ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/CIL7IOCDAQYA6HRJTP3ZCNRGYZWPTFQW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: New public C API functions must not steal references or return borrowed references
I (with a lot of help and input from other people) wrote up some of the thinking behind these kinds of API issues for the HPy project -- https://github.com/hpyproject/hpy/wiki/c-api-next-level-changes#what-needs-to-change-and-why It's written from an HPy point of view and if you've already thought about these things a lot none of it may be new to you and you may have your own opinions, but hopefully it's a good introduction to the issues if one is new to them. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6VHFDRL4T2IVS5ALDKD4M2ZY7HFDZGQN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?
Replying to the original email because my comment is more a thought after reading the whole thread rather than a response to any particular message. What I love about __version__ is that it is simple. It doesn't come with the complexity of solutions like `importlib.metadata.version`. The maintainers of the project arranged for it to be set**. It doesn't depend on how the module was packaged or distributed. I also don't think it's really a language update or requires any changes in the stdlib -- it's just a standard for the community to follow where none currently exists. It's also probably far from the end of the world*** if it doesn't happen, but I still like the idea. ** It might have been updated somewhat automatically -- my point here is that distutils, setuptools, packaging, pip, wheels, PyPI were all not involved. *** Although that is likely true of most PEPs, even much more complicated ones. :) Schiavo, Simon ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/O2LGPEIOZMJYDJ4GMZXMOQK7GDWYS6X5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?
Replying to myself to update my own thoughts:
I think __version__ and packaging tools answer separate questions.
__version__ answers the question of "this module I imported, what
version is it".
The packaging tools answer the question "what dependency does this
distribution satisfy".
This mismatch is why importlib.metadata.version("bs4") doesn't return
a useful answer. A single distribution might even install multiple
top-level modules with different versions.
Schiavo,
Simon
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/O242SRB6SBLBBMPCOLCKURBEXXHUSJZN/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: New pythoncapi_compat project adding Python 3.10 support to your C extensions without losing Python 2.7-3.9 support
On Thu, Jun 3, 2021 at 4:16 AM Victor Stinner wrote: > I would say that HPy is not complete nor mature yet. IMO it's already > worth it to start playing with it, try to convert your small C > extensions, and send back your early feedback to HPy developers! This is my view of the state of HPy too. It's a really good time to try things out and give feedback. Once we start doing more official releases, changing fundamental things about the HPy API will become harder (or at least more work). ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/P6AQ5TMFGOQUDCTSWBBQJK3SJRCUIKOJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [RELEASE] Python 3.10.0b3 is available
On Thu, Jun 17, 2021 at 11:36 PM Pablo Galindo Salgado wrote: > #And now for something completely different > > There are no green stars. Why? Thank you! This addition was great. :D ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PQHHFC2XHTXM3F5RBDELC5W5JN5XPLNA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Dropping out of this list
On Thu, Aug 19, 2021 at 4:15 AM Tim Peters wrote: > If you want more active moderation, volunteer for the job. I'd happily > give it up, and acknowledge that my laissez-faire moderation approach > is out of style. I, for one, welcome your laissez-faire moderation approach. :D ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/CVEMNLRVWFGHNTADZNHZW6SKXURMLLL4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: A ban from Core Developer spaces.
Hi Thomas, Could I ask a bit about the thinking behind extending the ban to a year? A year is a long time and to me feels similar to asking someone to go away and never come back. It's much longer than is needed to go away and think about things. Re the future of python-dev: That sounds a bit ominous. Is the Steering Council considering removing python-dev? Eek. Yours sincerely, Simon Cross ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XRCPPKUSA3ZVC3J2W2QGKLHO6NQHRTND/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [Steering-council] Re: A ban from Core Developer spaces.
Hi Brett, Thank you for the quick reply. On Thu, Aug 26, 2021 at 8:58 PM Brett Cannon wrote: > Marco was given a previous 3 month suspension on discuss.python.org (as Marco > himself pointed out on the email thread in question). Speaking for myself, > Marco was given a chance previously to take some time to think about how he > approached communicating and it didn't seem to be enough time. "A three month suspension was tried and didn't result in a better outcome" seems a solid reason for issuing a different suspension this time. Thank you for the background & explanation. > I will also note that Marco publicly asked me to ban him for life in one of > his emails in the thread as well. It seemed clear to me that Marco's statement was intended as a criticism of the banning process, or perhaps a request to be martyred. Either way, not really a good reason to impose or not impose a particular ban. Re python-dev's future: > I am purposefully not replying to this as I don't want to spark a > conversation on this topic in this email thread. Fair enough -- one topic per thread. However, as someone who engages primarily through python-dev, I would like some sort of more open debate on it's future on the list before anything drastic happens to it. /me heads off to sleep. - Simon ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PBPEKJBJKWXTGZDATRO7PJKCUDLLEAKD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: My apologies to the list
On Wed, Aug 25, 2021 at 9:28 PM Brett Cannon wrote: > I just wanted to apologize for any angst or noise my replies to Marco caused > folks. Caring enough to write this email shows that you are an awesome human (like many other humans). :D Please don't feel too bad about getting some mud on yourself -- this is just part of the territory of wading into messy situations in an attempt to help. Everyone else can also carry some of the responsibility for their own angst / emotions. We can all choose how we respond to unpleasant things if we pause and think to do so. - Simon ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/D3BAJPAVFWB5MBPZZ46J27HAY7DWPDLP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: A better way to freeze modules
Hi Gregory, I think adding a meta path importer that reads from a standard optimized format could be a great addition. As you mentioned in your email, this is a big detour from the current start-up performance work, so I think practically the people working on performance are unlikely to take a detour from their detour right now. If you would like to see your suggested feature in Python, I *think* the following might be a reasonable approach: * Email python-dev about your idea (done already! :) * Ask if there are any Python core developers who would be willing to look at the early stages of the code and/or PEP that you might produce in the next couple of steps. Perhaps also ask on one of the packaging mailing lists. If you get others involved as reviewers or contributors from the start, convincing them later that it is a good idea will be much easier. :) * Write the meta path importer in a separate package (it sounds like you've already done a lot of the work and gained a lot of understanding of the issues while writing PyOxidizer!) * Write a PEP. It seems to me that PEPs that come with an implementation and the support of a few existing core developers have a much less painful PEP review process. Thank you for writing PyOxidizer and offering some of your time to help make Python itself better. Yours sincerely, Simon Cross P.S. I am not a core developer, and I haven't even written any PEPs. :) ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LMHQ2S2YDJHQNQG3U65GIUPU6IB5QDXY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Thanks for your work in Python 3.10
Thank you for managing the release, Pablo! And for the awesome astrophysics snippets. :D ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/Y6RVLW6W7WLJNVQE6GXZHNUAUUKWP5LL/ Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-Dev] Accepting PEP 434, Idle Enhancement Exception
Having a standalone version of IDLE might be really useful to alternative Python implementations. ___ 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] __subclasses__() return order
I've used __subclasses__ as an easy way to register components by sub-classing a base component. I didn't rely on the ordering. I guess the current order depends on the order in which modules are imported and so is pretty fragile anyway? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2
On Mon, Aug 26, 2013 at 2:51 PM, Antoine Pitrou wrote: > Because this API is mostly useful when the data is received (*) at a > slow enough speed - which usually means from the network, not from a > hard drive. It looks like all the events have to be ready before one can start iterating over .events() in the new API? That doesn't seem that useful from an asynchronous programming perspective and .data_received() and .eof_received() appear to be thin wrappers over .feed() and .close()? Am I misunderstanding something? ___ 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] please back out changeset f903cf864191 before alpha-2
On Mon, Aug 26, 2013 at 5:57 PM, Antoine Pitrou wrote: > What do you mean, "all events have to be ready"? > If you look at the unit tests, the events are generated on-the-fly, > not at the end of the document. > (exactly the same as iterparse(), except that iterparse() is blocking) So you have to poll .events()? That also seems unhelpful from an event driven programming perspective. What I'm driving at is that I'd expect to have access to some sort of deferred that fires when the next event is ready to be processed and I don't see that here. ___ 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] Getting Tulip (PEP 3156) into the 3.4 stdlib, marked provisional, named asyncio
On Mon, Sep 30, 2013 at 1:51 AM, Larry Hastings wrote: > My guess is, a lot of people would be disappointed if Tulip missed 3.4. I > suspect the community would rather we slip the beta a little if it meant it > the difference between Tulip and no Tulip. +1 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The Tulip Has Landed
Yay! ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why does base64 return bytes?
On Tue, Jun 14, 2016 at 8:42 PM, Terry Reedy wrote: > Thank you for finding that. I reread it and still believe that bytes was > the right choice. Base64 is an generic edge encoding for binary data. It > fits in with the the standard paradigm as a edge encoding. I'd like to me-too Terry's sentiment, but also expand on it a bit. Base64 encoding is used to convert bytes into a limited set of symbols for inclusion in a stream of data. Whether bytes or unicode characters are appropriate depends on whether the stream being constructed is a byte stream or a unicode character stream. Many people do deal with byte streams in Python and we have large sub-communities for who this use case is important (e.g. Twisted, Asyncio, anyone using the socket module). It is also no longer 1980 though, and there are many protocols layered on top of unicode character streams rather than bytes. Ideally I'd like us to support both options (like we've been increasingly doing for reading from other external sources such as file systems or environment variables). If we only support one, I would prefer it to be bytes since (bytes -> bytes -> unicode) seems like less overhead and slightly conceptually clearer than (bytes -> unicode -> bytes), but I consider this a personal preference rather than any sort of one-true-way. Schiavo Simon ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Parsing f-strings from PEP 498 -- Literal String Interpolation
On Fri, Nov 4, 2016 at 9:56 AM, Eric V. Smith wrote: > 2. The parser sees that it's an f-string, and breaks it into expression and > text parts. I'm with Fabio here. It would be really nice to have a grammar specified and documented for this step, even if it's not implemented that way. Otherwise it's going to be very hard for, e.g., syntax highlighters to know what is intended to be allowed. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 550 v3 naming
What about "CoroutineScope" or "CoroutineContext"? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RFC] Removing pure Python implementation of OrderedDict
I thought the decision a few years ago was that all modules that have a C library for performance reasons should also have a Python version? Did this decision change at some point? (just curious). ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Packing a long list of numbers into memory
On Sun, Oct 10, 2021 at 4:23 PM Facundo Batista wrote: > > struct.pack_into(format, buffer, offset, v1, v2, ...) I've encountered this wart with pack and pack_into too. The current interface makes sense when if v1, v2 are a small number of items from a data record, but it becomes a bit silly when v1, v2, ... are the elements of an array of 10 000 integers, for example. The option to take a list-like argument like you suggest is a good idea, but maybe this should have its own function or is just outside the scope of the built-in struct module. Multiprocessing sort of added support for this via multiprocessing.Array -- see https://stackoverflow.com/questions/9754034/can-i-create-a-shared-multiarray-or-lists-of-lists-object-in-python-for-multipro. I haven't looked at what multiprocessing.Array does under the hood. Summary of the StackOverflow answer for those who don't feel like clicking: mp_arr = mp.Array(c.c_double, size) # then in each new process create a new numpy array using: arr = np.frombuffer(mp_arr.get_obj()) - Simon ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6S6Q437G3JS5TCKJ2SEKQ5DNRYMDZKIK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Python multithreading without the GIL
> Still, I hope you at least enjoyed my enthusiasm! I did! ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/BJFDVRCZMEDOHEMCCIJJP6NTX6HOGC5L/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Tool to search in the source code of PyPI top 5000 projects
It's really great to see data being gathered on the impact of changes. As we've already seen in this thread, there are many suggestions for how to gather more data and thoughts on how the methodology might be enhanced -- and these suggestions are great -- but just having a means to gather some important data is an excellent step. Anecdotes and people's mental models of the Python ecosystem are certainly valuable, but by themselves they don't provide a way to improve our joint view of the consequences of particular changes. As with unit tests and static analysis we should not expect such data gathering to provide complete proof that a change is okay to make, but having *some* quantitative data and the idea that we should pay attention to this data are definitely a big step forward. - Simon ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/QJJRIQXDJKFIR5YWJ2YLKEAYENWA35TP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Python no longer leaks memory at exit
> tl; dr Python no longer leaks memory at exit on the "python -c pass" command > ;-) Whooohooo! :D ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/M7P2L5CCLZ6NQXNZCJXAUYMSPB6G5I7N/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Defining tiered platform support
+10 on making the tier platform support explicit. I would vote not to require involving the SC in the tier changes unless there is a strong reason to do so (e.g. there is controversy, or e.g. Tier 1 implies a commitment of PSF infrastructure). The SC has a lot of decisions to make as it is & hopefully Tier 2 and 3 are really about checking a checklist (are there enough core devs committed, are the buildbots in place, etc) that is already defined in the PEP. Replies to some other replies in the thread: I like Christian's idea of explicitly supporting platforms such as manylinux2014, Debian stable, Ubuntu stable where C extensions are commonly built. It would help make those de facto standards more official. Or some of the platforms supported by cibuildwheel (to include non-Linux platforms). I would prefer having the list in a PEP rather than the devguide. The devguide is important, but it doesn't feel like a canonical reference place for this sort of information. Regards, Simon ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/W5DJ6QAALCJQPC2AYEW36F5VS63KV5MJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Switching to Discourse
I'm -1 on moving to the walled garden, but I don't expect this to change anyone's mind. I don't know if I'll move over to Discourse or not. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FE67QZEXBGVCJ5HMNLFVDJKETIE7N2UP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Switching to Discourse
> I can now pull from Discourse or GH when it’s convenient for me. It’s also > much easier to disengage for a few days and catch up later. I have a question about how you handle multiple communities. I'm subscribed to ~30 python-dev style mailing lists across different projects. There is no way I can open up 30 Discourse sites each day. Mail brings everything into one place for me, and I have things setup so that new mail from python-dev style lists is separated from my general inbox. Are you not subscribed to a bunch of communities? Or is there some way you aggregate or visit each forum that works nicely? Regards, Simon ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ZCJ6QAYXOTG7WZG5HHTLPBT6EZK3KBOM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Deprecating the "u" string literal prefix
On Tue, Dec 3, 2019 at 7:42 PM Guido van Rossum wrote: > I think it’s too soon to worry about this. I don’t see a reason to harass > people who maintain code based that were just recently migrated. > +100 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PSPKIXP4LE6UJBIJAVFECHVWK7GSI5KF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Can we stop adding to the C API, please?
Maybe we can have a two-for-one special? You can add a new function to the API if you deprecate two. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XE6ZO5Z4LKTJBVE3P77AMLR5SDQ2RQXA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 railroaded through?
On Fri, Jul 3, 2020 at 4:42 PM Rob Cliffe via Python-Dev < python-dev@python.org> wrote: > And since the PEP has Guido's authority behind it, I think > it is likely that it will eventually be accepted pretty much as it was > originally written. > This seems a bit unfair to Guido. He seems to put a lot of effort into taking onboard feedback and I would prefer it if the community encouraged long term contributors to keep contributing, rather than suggesting that this was somehow problematic (of course new contributors are good too, as are new-and-old contributors working together). Full disclosure: I'm not a huge fan of this PEP myself -- it seems to add a lot of new syntax to support a coding idiom that I consider an anti-pattern -- but others seem to have raised similar points to mine, so I think my point of view has already been fairly well represented in the discussion. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YCLL5H7NYKUEEBTQHPQSRQANV5JKFAQ4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: How to customize CPython to a minimal set
I don't know if they suit your purposes, but both sqlite3 and a small array implementation are already available: https://github.com/micropython/micropython-lib/tree/master/sqlite3 https://github.com/v923z/micropython-ulab ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ITYDEI7RKIDYKULJWK7H5HW32GZZQS3D/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PR checks hang because travis does not report back to github
On Sun, Oct 4, 2020 at 8:34 PM Mariatta wrote: > Perhaps we can relax the rule to allow administrators to merge the stuck PRs. > At least > temporarily until Travis/GitHub fixes it. Does this sound okay? +1 on relaxing the rule permanently. We should not give robots more rights than humans. People before Processes is the very first principle in the Agile Manifesto (and with good reason). ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WNGCNNETLTYD5TT2DCZZSWDHQ5PTB22C/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Thank you Larry Hastings!
Yay! Thanks Larry! And they were two of the releases which really helped Python 3 take off. :D ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/U3M5RTYDUTQGHTCZZ3UZPLPNB3DZAEWN/ Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-Dev] PEP 383: Non-decodable Bytes in System Character Interfaces
On Wed, Apr 22, 2009 at 8:50 AM, "Martin v. Löwis" wrote:
> For Python 3, one proposed solution is to provide two sets of APIs: a
> byte-oriented one, and a character-oriented one, where the
> character-oriented one would be limited to not being able to represent
> all data accurately. Unfortunately, for Windows, the situation would
> be exactly the opposite: the byte-oriented interface cannot represent
> all data; only the character-oriented API can. As a consequence,
> libraries and applications that want to support all user data in a
> cross-platform manner have to accept mish-mash of bytes and characters
> exactly in the way that caused endless troubles for Python 2.x.
Is the second part of this actually true? My understanding may be
flawed, but surely all Unicode data can be converted to and from bytes
using UTF-8? Obviously not all byte sequences are valid UTF-8, but
this doesn't prevent one from creating an arbitrary Unicode string
using "utf-8 bytes".decode("utf-8"). Given this, can't people who
must have access to all files / environment data just use the bytes
interface?
Disclosure: My gut reaction is that the solution described in the PEP
is a hack, but I'm hardly a character encoding expert. My feeling is
that the correct solution is to either standardise on the bytes
interface as the lowest common denominator, or to add a Path type (and
I guess an EnvironmentalData type) and use the new type to attempt to
hide the differences.
Schiavo
Simon
___
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] PEP 383: Non-decodable Bytes in System Character Interfaces
On Fri, Apr 24, 2009 at 12:04 PM, Glenn Linderman wrote: > The goal of Unicode users everywhere is to use Unicode for everything, no? > After all, all "real" file should have Unicode based names, and the only > proper byte sequences that should exist are UTF-8 encoding Unicode bytes. > (Cheek to tongue: Get out of here!) Humour aside :), the expectation that filenames are Unicode data simply doesn't agree with the reality of POSIX file systems. I think an approach similar to that adopted by glib [1] could work -- i.e. use the bytes API and provide some tools to assist application developers in converting them to and from Unicode strings (these tools are then where all the guess work about what encoding to use can live). [1] http://library.gnome.org/devel/glib/stable/glib-Character-Set-Conversion.html Schiavo Simon ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 383: Non-decodable Bytes in System Character Interfaces
On Fri, Apr 24, 2009 at 11:22 AM, Glenn Linderman wrote: > Oh clearly it is a hack. The right solution of a Path type (and friends) > was discarded in earlier discussion, because it would impact too much > existing code. The use of bytes would be annoying in the context of py3, > where things that you want to display are in str (Unicode). So there is no > solution that allows the use of str, and the robustness of bytes, and is > 100% compatible with existing practice. Hence the desire is to find a hack > that is "good enough". At least, that is my understanding and synopsis. What about keeping the bytes interface (utf-8 encoded Unicode on Windows) and adding a Path type (and friends) interface that mirrors it? > (Sorry Simon, but it is still the same thread, anyway.) Python discussions do seem to womble through a rather large set of mailing lists and news groups. :) Schiavo Simon ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 383: Non-decodable Bytes in System Character Interfaces
On Mon, Apr 27, 2009 at 9:48 PM, "Martin v. Löwis" wrote: > As Cameron says: it's out of the scope of the PEP. It really depends how > the operating system deals with them. Most likely, the files are not > accessible - not only not from Python, but also not accessible from > any other Unix program. Details depend on the specific operating system > software being used, and the specific parameters passed to it. $ touch $'\xFF\xAA\xFF' $ vi $'\xFF\xAA\xFF' $ egrep foo $'\xFF\xAA\xFF' All worked fine from my Bash shell with locale encoding set to UTF-8. I can also open the created file from the GNOME editor file dialog (it even tells me the filename is not valid in my locale's encoding). The Nedit editor also worked. So far I haven't found anything that failed. ___ 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] how to debug httplib slowness
On Fri, Sep 4, 2009 at 1:11 PM, Chris Withers wrote: > Am I right in reading this as most of the time is being spent in httplib's > HTTPResponse._read_chunked and none of the methods it calls? > > If so, is there a better way that a bunch of print statements to find where > in that method the time is being spent? Well, since the source for _read_chunked includes the comment # XXX This accumulates chunks by repeated string concatenation, # which is not efficient as the number or size of chunks gets big. you might gain some speed improvement with minimal effort by gathering the read data chunks into a list and then returning "".join(chunks) at the end. Schiavo Simon ___ 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] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
On Thu, Oct 8, 2009 at 10:31 AM, Tarek Ziadé wrote: > = Virtualenv and the multiple version support in Distribute = ... > My opinion is that this tool exists only because Python doesn't > support the installation of multiple versions for the same > distributions. This is not at all how I use virtualenv. For me virtualenv is a sandbox so that I don't have to become root whenever I need to install a Python package for testing purposes and to allow me to hop between sets of installed Python packages while developing on multiple Python projects. I also use it as a sandbox for build bots so that multiple bots on the same machine can each build their own projects with just the known dependencies installed. Schiavo Simon ___ 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] Backported faster RLock to Python 2.6.
On Thu, Jan 7, 2010 at 1:12 PM, Lennart Regebro wrote: > I'm not a license lawyer, but typically your company needs to give the > code to the community. Yes, it means it stops owning it. This is incorrect. The correct information is at http://www.python.org/psf/contrib/. Schiavo Simon ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 391 - Please Vote!
On Thu, Jan 14, 2010 at 11:23 AM, Vinay Sajip wrote: > So, can you please indicate your vote for or against incorporating PEP 391 > into Python? I think the dict configuration scheme will be a great addition to the logging module. :) Schiavo Simon ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3147: PYC Repository Directories
On Sun, Jan 31, 2010 at 1:54 PM, Hanno Schlichting wrote: > I'd be a big +1 to using a single ".pyr" directory per source directory. I don't know whether I in favour of using a single pyr folder or not but if a single folder is used I'd definitely prefer the folder to be called __pyr__ rather than .pyr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3147: PYC Repository Directories
On Sun, Jan 31, 2010 at 2:13 PM, Hanno Schlichting wrote: > On Sun, Jan 31, 2010 at 1:03 PM, Simon Cross > wrote: >> I don't know whether I in favour of using a single pyr folder or not >> but if a single folder is used I'd definitely prefer the folder to be >> called __pyr__ rather than .pyr. > > Do you have any specific reason for that? It rather not have the confusion caused by stray .pyc files multiplied by having said stray files buried in a hidden folder. > Using the leading dot notation is an established pattern to hide > non-essential information from directory views. What makes this > non-applicable in this situation and a custom Python notation better? Something being an established pattern doesn't mean it's a good idea. If we're go with an by-convention argument anyway surely Python conventions should take precedence -- this is *Python* after all. :) On the whole I'm against hiding folders because what information is non-essential varies from situation to situation. People (including me) regularly screw up dealing with .svn folders by including them in source tarballs, copying parts of one working copy into another, etc. Schiavo Simon ___ 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] __file__
On Wed, Feb 3, 2010 at 3:07 PM, Antoine Pitrou wrote: > Since there might be several compiled files for a single source file (for > example, a .pyc along with a JITted native .so), __cache__ should probably be > a > tuple rather than a string. But presumably there is only one compiled file that is in use by the current Python instance? Schiavo Simon ___ 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] Update xml.etree.ElementTree for Python 2.7 and 3.2
On Fri, Feb 19, 2010 at 7:40 AM, "Martin v. Löwis" wrote: >> Which most probably puts elementtree in bugfix-only mode. I don't >> necessarily disagree with such a decision, but it must be quite clear. The current situation is even worse than bugfix-only mode. Even bugfixes struggle to make it in. > My point is that the decision as already made when ElementTree was > incorporated into the standard library; it's the same policy for most > code that Fredrik Lundh has contributed (and which he still maintains > outside the standard library as well). He has made it fairly clear on > several occasions that this is how he expects things to work, and unless > we want to truly fork the code, we should comply. We need someone to maintain the copy of ElementTree in the Python repository. Ideally this means pulling upgrades and bugfixes from Fredrik's repository every now and then. If the goals of Python ElementTree and Fredrik ElementTree diverge I don't see a problem with an amicable fork. Fredrik and Python ElementTree do have rather different constraints (for example, Python ElementTree has fewer opportunities for breaking backwards compatibility). Schiavo Simon ___ 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] Update xml.etree.ElementTree for Python 2.7 and 3.2
On Sat, Feb 20, 2010 at 9:57 AM, "Martin v. Löwis" wrote: >> We need someone to maintain the copy of ElementTree in the Python >> repository. > > We have one: Fredrik Lundh. The last commits by Fredrik to ElementTree in Python SVN that I can see are dated 2006-08-16. The last commits I can see to ElementTree at http://svn.effbot.python-hosting.com/ are dated 2006-07-05. To paraphrase Antoine's comment [1] on Rietveld -- we need a process that results in bug fixes for users of the copy of ElementTree in Python. [1] http://codereview.appspot.com/207048/show (most direct link I could find) Schiavo Simon ___ 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] Update xml.etree.ElementTree for Python 2.7 and 3.2
On Sat, Feb 20, 2010 at 2:03 PM, "Martin v. Löwis" wrote: > I'd rather drop ElementTree from the standard library than fork it. Fork what? Upstream ElementTree is dead. Schiavo Simon ___ 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] Regarding socket timeouts in httplib
On Thu, Jul 1, 2010 at 10:33 AM, Anders Sandvig wrote: > 2) Modify HTTPConnection.connect() to set the timeout on the socket > object after it has been created (using the same timeout as given on > the HTTPConnection constructor). It looks like urllib2 in trunk and urllib.request in py3k are also affected by this oddity. My vote is for option 2 -- i.e. consider it a bug that the timeout wasn't consistently applied. Schiavo Simon ___ 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] Licensing // PSF // Motion of non-confidence
On Mon, Jul 5, 2010 at 11:05 PM, Nick Coghlan wrote: > As Brett noted, yes, the LICENSE file is complicated, but most people > don't bother reading it themselves - they ask what FSF and OSI think > of it, and get the answers "BSD style" and "GPL compatible" and are > happy with that. Presumably at least the BEOPEN.COM LICENSE AGREEMENT FOR PYTHON 2.0 can be removed from the LICENSE file because otherwise it appears that answer to "GPL compatible" must be no? Schiavo Simon ___ 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] Licensing
On Tue, Jul 6, 2010 at 11:05 PM, Terry Reedy wrote: > 1. Python License > > If there is not already, could there be an explanatory note, something like > (worded to be 'neutral': As a sub-point, I'd like to see something short explaining how the different licenses in the LICENSE file are meat to be combined. At the moment the terms and conditions section just lists them without explanation. Schiavo Simon ___ 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] Intended behavior of backlash in raw strings
On Tue, Jul 13, 2010 at 12:26 AM, John Arbash Meinel wrote: r"testing \" backslash and quote" > 'testing \\" backslash and quote' > > It happens that this is the behavior I want, but it seemed just as > likely to be an error. I tested it with python2.5 and 2.6 and got the > same results. The behaviour does appear to be explicitly documented in the language reference: """ When an 'r' or 'R' prefix is present, a character following a backslash is included in the string without change, and all backslashes are left in the string. For example, the string literal r"\n" consists of two characters: a backslash and a lowercase 'n'. String quotes can be escaped with a backslash, but the backslash remains in the string; for example, r"\"" is a valid string literal consisting of two characters: a backslash and a double quote; r"\" is not a valid string literal (even a raw string cannot end in an odd number of backslashes). """ Schiavo Simon ___ 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 signal processing question
On Tue, Jul 20, 2010 at 12:29 AM, Steve Holden wrote: > Another potential developer walks away feeling unwanted? Let just kill this thread here. SIGKILL can't be caught. :) (I had sort of assumed that Marcos was being ironic). Schiavo Simon ___ 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] Proposed tweaks to functools.wraps
On Wed, Aug 11, 2010 at 4:39 AM, Benjamin Peterson wrote: > Namespace conflict with what? I would prefer "wraps" unless it's > standardized as a behavior for all decorators. Having the original function available as __wrapped__ would be really cool, although I'm not quite sure what the behaviour should be in corner cases like: * The decorator returns the original function (I suppose a reference to itself is okay?) * The decorator returns the a function that is already decorating something else. Schiavo Simon ___ 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] Proposed tweaks to functools.wraps
On Wed, Aug 11, 2010 at 3:00 PM, Steven D'Aprano wrote: >> * The decorator returns the original function (I suppose a reference >> to itself is okay?) > > There's no reason why a function can't have an attribute that refers to > the function itself. It works fine: Yes. But it's more common for the original function to have be modified in some way. e.g.: def autodoc(f): f.__doc__ += document_args(f) return f @autodoc def f(x, y): """Add two numbers""" return x + y And then f.__wrapped__ is not particularly useful because the original function no longer exists and odd things will happen. For example, in the code above autodoc(f.__wrapped__).__doc__ will not equal f.__doc__. >> * The decorator returns the a function that is already decorating >> something else. > > That shouldn't make any difference. Given: > > @wraps(f) > def func(*args): > do_something() > return f(*args) > > then func.__wrapped__ gives f. If f itself wraps (say) g, and g wraps h, > then you have: I guess my description of the problem wasn't clear. I meant: def _debug(*args, **kwargs) print args, kwargs def mock(f): return _debug @mock def plus(a, b): return a + b @mock def prod(a, b): return a * b Schiavo Simon ___ 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] Proposed tweaks to functools.wraps
On Wed, Aug 11, 2010 at 11:21 PM, Nick Coghlan wrote: > However, as I noted before, these kinds of scenario are the reason we > decided that building this feature directly into the decorator > machinery wasn't a good idea. I agree. I was just replying to Steven's response to my post. :) Schiavo Simon ___ 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] question/comment about documentation of relative imports
On Tue, Oct 5, 2010 at 4:56 PM, Darren Dale wrote:
> from ...sys import path
>
> Note that while that last case is legal, it is certainly
> discouraged ("insane" was the word Guido used).
Only if by "legal" you mean "happened to work". It stops "happening to
work" in Python 2.6.6. :)
Generally I'm +0 on relative imports as a whole.
Schiavo
Simon
___
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] Continuing 2.x
2010/10/28 Kristján Valur Jónsson : > But the patient is very much alive and kicking, no matter what the good > doctor declares. No no! 'E's pining! Schiavo Simon ___ 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] Import and unicode: part two
On Wed, Jan 19, 2011 at 2:34 PM, Victor Stinner wrote: > (a) Python 3 doesn't support non-ASCII module names -0: I'm vaguely against this being supported because I'd rather not have to deal with what happens when the guess regarding the filesystem encoding is wrong. On the other hand, a general encouragement to stick to ASCII module names is probably functionally equivalent without imposing a hard restriction. > (b) Python 3 doesn't support unencodable characters in the module path +1: It'd be nice if Python could import modules regardless of what folder names people happen to have on their module path. Schiavo Simon ___ 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] Import and unicode: part two
On Wed, Jan 19, 2011 at 10:32 PM, Terry Reedy wrote: > I am a little shocked at the so-far tepid response to (a), so let me > defend and explain my claim that it is a bug. > > In the simplest case (from 6.11. The import statement and 2.3. Identifiers > and keywords) > > import_stmt ::= "import" module > module ::= indentifier > identifier ::= > > There is nothing, nothing, about any restriction on identifiers. I have no problem with non-ASCII module identifiers being valid syntax. It's a question of whether attempting to translate a non-ASCII module name into a file name (so the file can be imported) is a good idea and whether these sorts of files can be safely transferred among diverse filesystems. For similar reasons we tend to avoid capital letters in module names. Schiavo Simon ___ 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] Import and unicode: part two
On Wed, Jan 19, 2011 at 5:01 PM, Simon Cross wrote: > On Wed, Jan 19, 2011 at 2:34 PM, Victor Stinner > wrote: >> (a) Python 3 doesn't support non-ASCII module names > > -0: I'm vaguely against this being supported because I'd rather not > have to deal with what happens when the guess regarding the filesystem > encoding is wrong. On the other hand, a general encouragement to stick > to ASCII module names is probably functionally equivalent without > imposing a hard restriction. I'm changing my vote on this to a +1 for two reasons: * Initially I thought this wasn't supported by Python at all but I see that currently it is supported but that support is broken (or at least limited to UTF-8 filesystem encodings). Since support is there, might as well make it better (especially if it tidies up the code base at the same time). * I still don't think it's a good idea to give modules non-ASCII names but the "consenting adults" approach suggests we should let people shoot themselves in the foot if they believe they have good reason to do so. Schiavo Simon ___ 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] devguide: Generate patches without code checkout (Was: devguide: Write a guide to committing a patch.)
On Wed, Feb 2, 2011 at 10:33 AM, anatoly techtonik wrote: > How about patches sent by users who track and fix bugs directly in > codebase of their Python installation? While I don't personally endorse the above approach, if you're going to develop inside your installed site-packages folder it seems like a good idea to at least version control that code by running "hg init" or similar in the site-packages folder. Then you can create diffs against older versions using "hg diff". If one is going to do something crazy one might as well go the whole hog I guess. :) Schiavo Simon ___ 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] alternate fix for urllib2 bug #8797
Hi Sam On Wed, Feb 2, 2011 at 5:55 PM, Sam Bull wrote: > This is my first stab at contributing to this list. I'm writing to lobby for > bug #8797's fix to be removed and for my fix to put in in its place. For what it's worth, I was already about to include your patch as a workaround for the bug in 2.6. See Bitten issue http://bitten.edgewall.org/ticket/658. I also consider Sam's patch to be a cleaner patch than the one that ended up being applied in Python. See my comments in the Bitten mailing list thread: https://groups.google.com/forum/#!topic/bitten/niJENqEGuus. Schiavo Simon ___ 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] Integrate the faulthandler module into Python 3.3?
On Fri, Mar 4, 2011 at 2:58 AM, Victor Stinner wrote: > Some months ago, I proposed a patch to display the Python backtrace on a > segfault. The API was not stable, it was too for Python 3.2, and it was > enabled by default. I wrote a module instead of a patch so it can be > used on any version of Python, and it has a better API. And now I would > like to include the module into Python directly to use it more easily. > See http://bugs.python.org/issue11393 for the details. The module: While I like this module I'm against it going into the standard library so soon. Modules need time to mature, develop and gain wide adoption outside the standard library where they are less constrained by maintaining compatibility with old versions and can enjoy shorter release cycles. There may be reasons for including a shiny new module in the standard library despite the drawbacks (the rest of the standard library might wish to use the new feature, for example). If there are such reasons it would be nice to see them stated and discussed here. Schiavo Simon ___ 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] Integrate the faulthandler module into Python 3.3?
On Fri, Mar 4, 2011 at 3:26 PM, Victor Stinner wrote: > faulthandler is also a little bit special, because it is very specific > to CPython: it is based on CPython internal structures. If faulthandler is a public part of the standard library, what should other Python implementations do about implementing it? Schiavo Simon ___ 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] sprints and pushes
On Wed, Mar 23, 2011 at 7:24 PM, Antoine Pitrou wrote: > On Wed, 23 Mar 2011 10:25:01 -0700 > Ethan Furman wrote: >> >> I think the use-case has been lost. Think sprints and multiple push >> races. No one is arguing that the smoke-test should be the default, but >> seriously, are you willing to spend an hour or more re-running the >> complete suite of tests six, eight, or 12 times because of push races in >> a sprint? I can see losing a good portion of your sprinting day. Our sprint model has been to set up a throw-away sprint repository somewhere accessible (github, bitbucket, wherever) and have everyone commit madly to it however they want. Afterwards a few brace souls take the result and commit it to the master repository in a more orderly fashion. ___ 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] Proposal for Python 3.3: dependence injection
On Fri, Mar 25, 2011 at 1:25 AM, Nick Coghlan wrote: > As an example of the last point, perhaps rather than modifying all the > *clients* of the socket module, it may make more sense to have tools > in the socket module itself to temporarily customise the socket > creation process in the current thread. The advantage of such an > approach is that it would then work for 3rd party libraries that > create sockets, without requiring any further modification. -2. That wouldn't allow one to use normal sockets in one 3rd party library and special sockets in another 3rd party library. Schiavo Simon ___ 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] Please revert autofolding of tracker edit form
On Thu, Mar 31, 2011 at 12:54 AM, Nick Coghlan wrote: > Interesting - it comes straight up with the folded screen for me, no > flickering at all. I didn't get any flicker either and my first impression of the change was also positive -- I usually skip straight to the comments the first time I visit an issue. Schiavo Simon ___ 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] optimization required: .format() is much slower than %
On Tue, May 27, 2008 at 12:43 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Ten minutes ago I raised a concern about speed differences between the
> old style % formatting and the new .format() code. Some quick
> benchmarking from Benjamin and me showed, that it's even worse than I
> expected.
My own tests show a less dire difference:
$ ./python -m timeit "'some text with %s'.format('nothing')"
100 loops, best of 3: 0.578 usec per loop
$ ./python -m timeit "'some text with %s' % 'nothing'"
100 loops, best of 3: 0.472 usec per loop
> $ ./python -m timeit "'%s'.format('nothing')"
> 10 loops, best of 3: 2.63 usec per loop
> $ ./python -m timeit "'%s' % 'nothing'"
> 1000 loops, best of 3: 0.188 usec per loop
It struct me as odd that this one case shows such a big difference
while the others show less of one.
My tests show that the old-style % formatting is much faster when the
final string is 20 characters or less:
$ ./python -m timeit "'|||...%s' % '12'"
1000 loops, best of 3: 0.0764 usec per loop
$ ./python -m timeit "'|||...%s' % '123'"
100 loops, best of 3: 0.481 usec per loop
A read through stringobject.c didn't give me any clue as to why 20 is
the magic number. %d shows an even bigger jump:
$ ./python -m timeit "'|||...%d' % 12"
1000 loops, best of 3: 0.0764 usec per loop
$ ./python -m timeit "'|||...%d' % 123"
100 loops, best of 3: 1.28 usec per loop
Schiavo
Simon
___
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] Exception.__unicode__ and tp_unicode
Originally Python exceptions had no __unicode__ method. In Python 2.5 __unicode__ was added. This led to "unicode(Exception)" failing and so the addition of __unicode__ was reverted [1]. This leaves Python 2.6 in a position where calls to "unicode(Exception(u'\xe1'))" fail as they are equivalent to "uncode(str(Exception(u'\xe1'))" which cannot convert the non-ASCII character to ASCII (or other default encoding) [2]. >From here there are 3 options: 1) Leave things as they are. 2) Add back __unicode__ and have "unicode(Exception)" fail. 3) Add a tp_unicode slot to Python objects and have everything work (at the cost of adding the slot). Each option has its draw backs. Ideally I'd like to see 3) implemented (there are already two volunteers for and some initial stabs at implementing it) but a change to Object is going to need an okay from someone quite high up. Also, if you know of any code this would break, now is the time to let me know. If we can't have 3) I'd like to see us fall back to option 2). Passing unicode exceptions back is useful in a number of common situations (non-English exception messages, database errors, pretty much anywhere that something goes wrong while dealing with potentially non-ASCII text) and encoding to some specific format is usually not an option since there is no way to know where the exception will eventually be caught. Also, unicode(ClassA) already fails for any class that implements __unicode__ so even without this effecting Exception it's already not safe to do u"%s" % SomeClass. Also, there is a readily available work around by doing u"%s" % str(SomeClass). I'm opposed to 1) because a full work around means doing something like: def unicode_exception(e): if len(e.args) == 0: return u"" elif len(e.args) == 1: return unicode(e.args[0]) else: return unicode(e.args) and then using unicode_exception(...) instead of unicode(...) whenever one needs to get a unicode value for an exception. The issue doesn't affect Python 3.0 where unicode(...) is replaced by str(...). [1] http://bugs.python.org/issue1551432 [2] http://bugs.python.org/issue2517 Schiavo Simon ___ 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] Exception.__unicode__ and tp_unicode
On Wed, Jun 11, 2008 at 11:34 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > 4) Fix PyObject_Unicode to not retrieve __unicode__ from new-style > instances, and instead only look for the method on their types (similar to > the way PyObject_Format looks up the __format__ method). Thanks for the suggestion Nick. I've added a patch which implements it to the bug. Schiavo Simon ___ 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] bugs.python.org down
On Thu, Jun 12, 2008 at 11:48 AM, anton <[EMAIL PROTECTED]> wrote: > ping works but http://bugs.python.org giges after a timeout: Seeing the same thing here, so it's not just you. Schiavo Simon ___ 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
