> 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'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
ht
+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 & hopef
> 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/py
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
imp
> 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
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
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.py
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-D
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 your
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 tak
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/
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
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 sen
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.
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 misma
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 maintaine
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
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
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.
_
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
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 ha
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
ht
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
ou'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
+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
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 det
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 unsub
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 interna
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 p
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-
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.
Peo
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 --
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
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/py
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@pytho
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
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! :)
_
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 Pytho
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 o
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-d
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-De
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.
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?
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 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
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
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 Deprecati
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 seem
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
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://
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
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
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 sent
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:
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
___
P
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
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
___
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
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 .eve
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 ma
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/pyt
On Sun, Feb 10, 2013 at 2:32 PM, Nick Coghlan wrote:
> For those that don't recall the original discussion, the proposal is
> to add a new __init_class__ hook, invoked after the class object is
> created, but before the class decorators are applied. This provides a
> simple approach to inherited p
On Mon, Feb 4, 2013 at 12:16 AM, Vinay Sajip wrote:
> Bento is interesting, but I wouldn't jump to heap praise onto it. Apart from
> the
> somewhat idiosyncratic source style, David Cournapeau himself points to what
> he
> regards as weaknesses in it[1].
For the record, all the reasons listed a
On Sun, Feb 3, 2013 at 9:42 PM, Daniel Holth wrote:
> Bento is the only available packaging tool to heap praise onto and it is
> impressive.
If Bento is cool, is there some way we can help it gain more traction
in the Python ecosystem? Not necessarily by incorporating it into
stdlib, but perhaps
On Sat, Jan 19, 2013 at 9:30 PM, Benjamin Peterson wrote:
> It's been almost a year since 2.7.3, so it's time for another 2.7
> bugfix release.
>
> 2013-02-02 - 2.7.4 release branch created; rc released
> 2013-02-16 - 2.7.4 released
The Cape Town Python User Group is having a Python Bug Day next
On Sat, Mar 3, 2012 at 1:38 AM, R. David Murray wrote:
> What is even more fun is that the append actually worked (try printing
> l).
Now that is just weird. :)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
l[0] += [1]
is the same as
l[0] = l[0] + [1]
Does that make the reason for the error clearer? The problem is the
attempt to assign a value to l[0].
It is not the same as
e = l[0]
e += [1]
which is the equivalent to
e = l[0]
e = e + [1]
This never assigns a value to l[0].
Schiavo
Simon
On Mon, Feb 27, 2012 at 5:44 PM, Armin Ronacher
wrote:
> Agile development and unittests. An installation hook means that you
> need to install the package before running the tests. Which is fine for
> CI but horrible during development. "python3 run-tests.py" beats "make
> venv; install librar
On Sun, Feb 26, 2012 at 6:12 PM, Larry Hastings wrote:
> It's probably neutral. But I do have one question: can you foresee the
> scientific community moving to a finer resolution than nanoseconds in our
> lifetimes?
I think we're already there. Even just in radio astronomy new arrays
like ALMA
On Sun, Feb 26, 2012 at 1:31 AM, Guido van Rossum wrote:
> I still think that when you are actually interested in *using* times,
> the current float format is absolutely fine. Anybody who thinks they
> need to accurately know the absolute time that something happened with
> nanosecond accuracy is
On Thu, Feb 9, 2012 at 2:35 AM, Steven D'Aprano wrote:
> Simon Cross wrote:
>>
>> I think I'm -1 on a "locale" encoding because it refers to different
>> actual encodings depending on where and when it's run, which seems
>> surprising
>
>
On Wed, Feb 8, 2012 at 3:25 PM, Victor Stinner
wrote:
> The current locale is process-wide: if a thread changes the locale,
> all threads are affected. Some functions have to use the current
> locale encoding, and not the locale encoding read at startup. Examples
> with C functions: strerror(), st
On Wed, Feb 8, 2012 at 3:25 PM, Victor Stinner
wrote:
> Sorry, I don't understand what do you mean by "weird things". The
> "locale" codec doesn't touch the locale.
Sorry for being unclear. My question was about the following lines
from http://docs.python.org/library/locale.html#locale.getpreferr
I think I'm -1 on a "locale" encoding because it refers to different
actual encodings depending on where and when it's run, which seems
surprising, and there's already a more explicit way to achieve the
same effect.
The documentation on .getpreferredencoding() says some scary things
about needing
Is the idea to have:
b"foo".decode("locale")
be roughly equivalent to
encoding = locale.getpreferredencoding(False)
b"foo".decode(encoding)
?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Un
On Sat, Jan 28, 2012 at 9:49 AM, Matt Joiner wrote:
> FWIW I'm now -1 for this idea. Stronger integration with PyPI and
> packaging systems is much preferable. Python core public releases are
> no place for testing.
+1. I'd much rather just use the module from PyPI.
It would be good to have a pr
On Wed, Nov 23, 2011 at 6:50 AM, Senthil Kumaran wrote:
> That's cool. But just my thought, wouldn't it be better for someone
> who regularly commits, fixes bugs and feature requests be better for a
> RM role? Once a developer gets bored with those and wants more, could
> take up RM role. Is ther
On Sun, Oct 2, 2011 at 7:23 PM, Simon Cross
wrote:
> I'm -1 on hacking += to be fast again because having the two loops
> below perform wildly differently is *very* surprising to me:
>
> s = ''
> for x in loops:
> s += x
>
> s = ''
> for
On Sat, Oct 1, 2011 at 7:17 PM, Victor Stinner
wrote:
> I'm writing this email to ask you if this type solves a real issue, or if we
> can just prove the super-fast str.join(list of str).
I'm -1 on hacking += to be fast again because having the two loops
below perform wildly differently is *very*
On Wed, Sep 7, 2011 at 6:31 PM, Simon Cross
wrote:
> http://www.google.com/codesearch#search/&q=swapcase%20lang:%5Epython$&type=cs
>
> There are quite a few hits but more people appear to be
> re-implementing it than using it (I haven't gone to the trouble of
> mining
On Tue, Sep 6, 2011 at 10:36 PM, "Martin v. Löwis" wrote:
>> Which applications? I'm not sure the number of applications using
>> str.swapcase gets even as high as ten.
>
> I think this is what people underestimate. I can't name
> applications either - but that doesn't mean they don't exist.
> I'm
On Sun, Aug 28, 2011 at 6:58 AM, Terry Reedy wrote:
> 2) It is not trivial to use it correctly. I think it needs a SWIG-like
> companion script that can write at least first-pass ctypes code from the .h
> header files. Or maybe it could/should use header info at runtime (with the
> .h bundled with
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 vis
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 t
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
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 impl
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
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
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 see
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 w
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" m
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
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/
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. :)
General
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
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 th
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
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
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
1 - 100 of 135 matches
Mail list logo
